diff --git a/content/en/archived-docs/apps/bankinabox/user-interface/how-to.md b/content/en/archived-docs/apps/bankinabox/user-interface/how-to.md index 12010c51457..6365a8b585d 100644 --- a/content/en/archived-docs/apps/bankinabox/user-interface/how-to.md +++ b/content/en/archived-docs/apps/bankinabox/user-interface/how-to.md @@ -69,7 +69,7 @@ Follow these steps to create a new customer profile. When the customer profile is created, they will not have any accounts - you will have to create them. Learn how under [Creating accounts](#create-a-current-account). {{< /note >}} -{{< figure alt="Create customer profile" width=80% zoom="/en/gifs/create-customer-biab-1.0.gif" >}} +{{< figure alt="Create customer profile" width=80% src="/en/gifs/create-customer-biab-1.0.gif" >}} ### Create a Current account @@ -93,7 +93,7 @@ When the customer profile is created, they will not have any accounts - you will 7. When an account is created, it is in **PENDING** status. This must be changed to **ACTIVE** for a customer to be able to interact with and use the account. See [Change an account status](#change-an-account-status) for more information. -{{< figure alt="Create account" width=80% zoom="/en/gifs/create-current-account-biab-1.0.gif" >}} +{{< figure alt="Create account" width=80% src="/en/gifs/create-current-account-biab-1.0.gif" >}} ### Create a Savings account @@ -139,7 +139,7 @@ An account has three statuses: **PENDING**, **ACTIVE**, and **SUSPENDED**. When If the account needs to be suspended, follow the same steps but select **SUSPENDED**. -{{< figure alt="Set account status" width=80% zoom="/en/gifs/set-account-status-biab-1.0.gif" >}} +{{< figure alt="Set account status" width=80% src="/en/gifs/set-account-status-biab-1.0.gif" >}} ### Assign or revoke a user role @@ -162,7 +162,7 @@ To assign a user role, follow these steps: 5. Click **Revoke**. A message will appear indicating that the user role was assigned successfully. -{{< figure alt="Assign role" width=80% zoom="/en/gifs/assign-a-role-biab-1.0.gif" >}} +{{< figure alt="Assign role" width=80% src="/en/gifs/assign-a-role-biab-1.0.gif" >}} #### Revoke a user role @@ -178,7 +178,7 @@ To revoke a user role, follow these steps: 5. Click **Save**. A message will appear indicating that the user role was revoked successfully. -{{< figure alt="Revoke role" width=80% zoom="/en/gifs/revoke-role-biab-1.0.gif" >}} +{{< figure alt="Revoke role" width=80% src="/en/gifs/revoke-role-biab-1.0.gif" >}} ### Issue a loan @@ -194,7 +194,7 @@ Once the account has been set to **ACTIVE**, you will have the ability to issue A loan account is created when a loan has been issued successfully. -{{< figure alt="Issue loan" width=80% zoom="/en/gifs/issue-loan-biab-1.0.gif" >}} +{{< figure alt="Issue loan" width=80% src="/en/gifs/issue-loan-biab-1.0.gif" >}} ### Approve overdrafts @@ -214,7 +214,7 @@ To approve an overdraft, follow these steps. Overdrafts can be approved whether the account is **PENDING**, **ACTIVE**, or **SUSPENDED**. {{< /note >}} -{{< figure alt="Approve overdraft" width=80% zoom="/en/gifs/approve-overdraft-biab-1.0.gif" >}} +{{< figure alt="Approve overdraft" width=80% src="/en/gifs/approve-overdraft-biab-1.0.gif" >}} ### Deposit money to an account @@ -229,7 +229,7 @@ Follow these steps to deposit money to a customer account. 4. Click **Save**. You will receive a message indicating that the deposit was successful. -{{< figure alt="Deposit" width=80% zoom="/en/gifs/deposit-biab-1.0.gif" >}} +{{< figure alt="Deposit" width=80% src="/en/gifs/deposit-biab-1.0.gif" >}} ### Register as a user on Bank in a Box @@ -250,7 +250,7 @@ You must be registered as a **Customer** or **Admin** on Bank in a Box to perfor 5. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update customer profile @@ -283,7 +283,7 @@ An **Admin user** can set an account's **Withdrawal daily limit** or **Transfer 2. Click **Save** when you've entered the desired limits. A message will appear indicating that the limits have been saved successfully. -{{< figure alt="Set withdrawal and transfer limits - admin" width=80% zoom="/en/gifs/set-limits-admin-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - admin" width=80% src="/en/gifs/set-limits-admin-biab-1.0.gif" >}} ## Customer tasks @@ -308,12 +308,12 @@ Follow these steps to create a new intrabank payment. 6. Click **Save**. You will receive a notification indicating that the payment was created successfully. You will also receive notifications indicating any changes in your account balances. -{{< figure alt="Create intrabank payment" width=80% zoom="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} +{{< figure alt="Create intrabank payment" width=80% src="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} After making a payment, you can view the details of this transaction on the Transactions screen. -{{< figure alt="View transaction" width="800" width=80% zoom="/en/gifs/view-transaction-biab-1.0.gif" >}} +{{< figure alt="View transaction" width="800" width=80% src="/en/gifs/view-transaction-biab-1.0.gif" >}} ### Create a recurring payment @@ -337,7 +337,7 @@ Follow these steps to create a recurring payment: 3. You will be taken back to the **Recurring payments screen** where you will receive a message indicating that the recurring payment was created successfully. -{{< figure alt="Recurring payment" width=80% zoom="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} +{{< figure alt="Recurring payment" width=80% src="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} {{< note >}} This payment will not appear on the **Recurring payments screen** until the first iteration has occurred. @@ -366,7 +366,7 @@ You must be registered as a Customer or Admin on Bank in a Box to perform tasks. 7. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update a customer profile @@ -405,4 +405,4 @@ To set these limits as a **Customer**, follow these steps. 4. Click **Save**. You will be taken back to the Account page where you will receive a message indicating that the limits have been updated successfully. -{{< figure alt="Set withdrawal and transfer limits - customer" width=80% zoom="/en/gifs/set-limits-customer-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - customer" width=80% src="/en/gifs/set-limits-customer-biab-1.0.gif" >}} diff --git a/content/en/archived-docs/corda-5/5.0-dev-preview-1/cordapps/key-concepts/key-concepts-ledger.md b/content/en/archived-docs/corda-5/5.0-dev-preview-1/cordapps/key-concepts/key-concepts-ledger.md index 63040ff9174..c69a15a8d8d 100644 --- a/content/en/archived-docs/corda-5/5.0-dev-preview-1/cordapps/key-concepts/key-concepts-ledger.md +++ b/content/en/archived-docs/corda-5/5.0-dev-preview-1/cordapps/key-concepts/key-concepts-ledger.md @@ -22,7 +22,7 @@ The facts that a node knows about are those that it is involved with. For exampl Look at this example in a network with five nodes, where each numbered circle on an intersection represents a fact shared between two or more nodes. -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} The Venn diagram above represents 5 nodes (Alice, Bob, Carl, Demi, and Ed) as sets. Where the sets overlap are shared facts, such as those known by both Alice and Bob (1 and 7). @@ -36,7 +36,7 @@ In the previous diagram, we could see that although Carl, Demi, and Ed are aware You can think of this vault as being a database or simple table. -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} Where the rows are shared between nodes (facts 1 and 7 in this example), these are shared facts. diff --git a/content/en/archived-docs/corda-5/5.0-dev-preview-1/cordapps/key-concepts/key-concepts-states.md b/content/en/archived-docs/corda-5/5.0-dev-preview-1/cordapps/key-concepts/key-concepts-states.md index 89262b2d2dd..06cc83009df 100644 --- a/content/en/archived-docs/corda-5/5.0-dev-preview-1/cordapps/key-concepts/key-concepts-states.md +++ b/content/en/archived-docs/corda-5/5.0-dev-preview-1/cordapps/key-concepts/key-concepts-states.md @@ -16,7 +16,7 @@ and identity information. For example, this state represents an IOU—an agreement that Alice owes Bob £5: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} As well as any information about the fact itself, the state also contains a reference to the **contract** that governs the evolution of the state over time. @@ -35,14 +35,14 @@ version of the state (which represents the updated fact) and mark the existing s This sequence of state replacements gives you a full view of the evolution of the shared fact over time: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a **vault**—a database which tracks all the current and historic states that the node is aware of and considers to be relevant (to itself): -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} The **ledger** is all the current (non-historic) states that a particular node is aware of. diff --git a/content/en/archived-docs/corda-5/5.0-dev-preview-1/cordapps/key-concepts/key-concepts-transactions.md b/content/en/archived-docs/corda-5/5.0-dev-preview-1/cordapps/key-concepts/key-concepts-transactions.md index bc227ef9fd6..1b16d78c26f 100644 --- a/content/en/archived-docs/corda-5/5.0-dev-preview-1/cordapps/key-concepts/key-concepts-transactions.md +++ b/content/en/archived-docs/corda-5/5.0-dev-preview-1/cordapps/key-concepts/key-concepts-transactions.md @@ -25,7 +25,7 @@ in the same way), when writing states you must add a `JsonRepresentable`. Here's an example of a transaction, with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs, and references. They can: @@ -52,24 +52,24 @@ Input state references are a combination of: These input state references link transactions together, forming a *transaction chain*: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} ## Committing transactions Initially, a transaction is just a *proposal* to update the ledger. It represents the future state of the ledger that is desired by the transaction builders: -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To become reality, the transaction must receive signatures from all *required signers* (see **[commands](#commands)**). Each required signer appends their signature to the transaction to indicate that they accept the proposal: -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If all required signatures are gathered, the transaction becomes committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that the transaction's: @@ -119,7 +119,7 @@ For example, a transaction where Alice uses a £5 cash payment to pay off £5 of It also has two supporting attachments, and will only be notarised by NotaryClusterA if the notary pool receives it within the specified time-window. This transaction would look like: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -144,7 +144,7 @@ listed in the commands, you get the list of the transaction’s required signers Here's a visualization of this example. -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/archived-docs/corda-5/5.0-dev-preview-1/getting-started/troubleshooting/network-troubleshooting.md b/content/en/archived-docs/corda-5/5.0-dev-preview-1/getting-started/troubleshooting/network-troubleshooting.md index 446df1ab71b..ef87e04c860 100644 --- a/content/en/archived-docs/corda-5/5.0-dev-preview-1/getting-started/troubleshooting/network-troubleshooting.md +++ b/content/en/archived-docs/corda-5/5.0-dev-preview-1/getting-started/troubleshooting/network-troubleshooting.md @@ -54,10 +54,9 @@ ERROR: for smoke-tests-network-bootstrapper Cannot create container for service To resolve this, add the path to the **File sharing** options: -{{< - figure +{{< figure src="docker-windows-file-sharing.png" - zoom="docker-windows-file-sharing.png" + width=80% figcaption="Docker Windows File Sharing" alt="docker windows file sharing" diff --git a/content/en/archived-docs/corda-5/5.0-dev-preview-1/nodes/developing/durable-streams/durable-streams-homepage.md b/content/en/archived-docs/corda-5/5.0-dev-preview-1/nodes/developing/durable-streams/durable-streams-homepage.md index a6d5a06a001..440a4f1b5d5 100644 --- a/content/en/archived-docs/corda-5/5.0-dev-preview-1/nodes/developing/durable-streams/durable-streams-homepage.md +++ b/content/en/archived-docs/corda-5/5.0-dev-preview-1/nodes/developing/durable-streams/durable-streams-homepage.md @@ -41,10 +41,9 @@ element. However, there are a few rules: * The value can only increase from one element to the next. * Once a position has been created, it cannot be changed. -{{< - figure +{{< figure src="1.png" - zoom="1.png" + width=80% figcaption="Transactional elements with positions" alt="Transactional elements with positions" @@ -57,10 +56,9 @@ An HTTP-RPC client can make durable query polling requests to retrieve a sub-set * Position where it left off or `-1` if this is the first polling request for a set of parameters. * Maximum number of elements it is prepared to consume in the server response. `3` has been used in this example. -{{< - figure +{{< figure src="2.png" - zoom="2.png" + width=80% figcaption="First durable query polling request" alt="First durable query polling request" @@ -74,10 +72,9 @@ and processing server side responses at varying speeds. A second client could make a separate polling request to the server using different parameters, resulting in a different set of transactional elements: -{{< - figure +{{< figure src="3.png" - zoom="3.png" + width=80% figcaption="Second client durable query polling request" alt="Second client durable query polling request" @@ -90,10 +87,9 @@ server. Clients progress through the elements of the stream at their own pace. Once the first client has processed the server's reply, it can make a second polling request: -{{< - figure +{{< figure src="4.png" - zoom="4.png" + width=80% figcaption="First client, second poll" alt="First client, second poll" diff --git a/content/en/archived-docs/corda-5/5.0-dev-preview-1/nodes/operating/cli-curl/cli-curl.md b/content/en/archived-docs/corda-5/5.0-dev-preview-1/nodes/operating/cli-curl/cli-curl.md index 504c40f9865..d6a2b8c6c66 100644 --- a/content/en/archived-docs/corda-5/5.0-dev-preview-1/nodes/operating/cli-curl/cli-curl.md +++ b/content/en/archived-docs/corda-5/5.0-dev-preview-1/nodes/operating/cli-curl/cli-curl.md @@ -178,10 +178,9 @@ curl -u default -X GET "https://0.0.0.0:9090/api/v1/flowmanagerrpcops/listactive You may find it useful to look at the `curl` commands generated by Swagger UI. These become visible once you have sent a request in the `Try it out` section of an operation: -{{< - figure +{{< figure src="tryitout.png" - zoom="tryitout.png" + width=80% figcaption="curl commands in Swagger UI" alt="curl commands in Swagger UI" diff --git a/content/en/archived-docs/corda-5/5.0-dev-preview-1/tutorials/building-cordapp/c5-basic-cordapp-ui.md b/content/en/archived-docs/corda-5/5.0-dev-preview-1/tutorials/building-cordapp/c5-basic-cordapp-ui.md index 935ec496152..fd85e68590e 100644 --- a/content/en/archived-docs/corda-5/5.0-dev-preview-1/tutorials/building-cordapp/c5-basic-cordapp-ui.md +++ b/content/en/archived-docs/corda-5/5.0-dev-preview-1/tutorials/building-cordapp/c5-basic-cordapp-ui.md @@ -55,10 +55,9 @@ After you have deployed your CorDapp to a local Corda 5 network and the back-end The Mission Mars CorDapp UI opens in your browser window. -{{< - figure +{{< figure src="mission-mars-ui.PNG" - zoom="mission-mars-ui.PNG" + width=100% figcaption="Mission Mars CorDapp UI" alt="mission mars cordapp ui" diff --git a/content/en/archived-docs/corda-5/5.0-dev-preview-1/tutorials/run-demo-cordapp.md b/content/en/archived-docs/corda-5/5.0-dev-preview-1/tutorials/run-demo-cordapp.md index 1c3408aaa20..8c4a4f32b78 100644 --- a/content/en/archived-docs/corda-5/5.0-dev-preview-1/tutorials/run-demo-cordapp.md +++ b/content/en/archived-docs/corda-5/5.0-dev-preview-1/tutorials/run-demo-cordapp.md @@ -330,19 +330,17 @@ Follow these steps to start up the UI: 4. Visit [http://localhost:3000/](http://localhost:3000/) to test the UI. -{{< - figure +{{< figure src="solar-system-home.png" - zoom="solar-system-home.png" + width=100% figcaption="Solar System CorDapp UI" alt="Solar system CorDapp UI" >}} -{{< - figure +{{< figure src="solar-system-earth.png" - zoom="solar-system-earth.png" + width=100% figcaption="Solar System CorDapp UI - Earth" alt="Solar system CorDapp UI - Earth" diff --git a/content/en/archived-docs/corda-enterprise/4.3/performance-testing/introduction.md b/content/en/archived-docs/corda-enterprise/4.3/performance-testing/introduction.md index 4e349acacdc..d9aeb0fba83 100644 --- a/content/en/archived-docs/corda-enterprise/4.3/performance-testing/introduction.md +++ b/content/en/archived-docs/corda-enterprise/4.3/performance-testing/introduction.md @@ -114,7 +114,7 @@ measuring the throughput of a node, the test definition instructs all JMeter ser thus saturating the RPC handler and driving the node as hard as possible. The test typically e.g. issues cash on the node (no interaction with other nodes) or sends cash to a second node which requires sending P2P messages back and forth. -{{< figure alt="jmeter network overview" width=80% zoom="/en/jmeter-network-overview.png" >}} +{{< figure alt="jmeter network overview" width=80% src="/en/jmeter-network-overview.png" >}} ## Performance Tests diff --git a/content/en/archived-docs/corda-enterprise/4.3/performance-testing/jmeter-samplers.md b/content/en/archived-docs/corda-enterprise/4.3/performance-testing/jmeter-samplers.md index 12b7c136cb8..81a7b51700e 100644 --- a/content/en/archived-docs/corda-enterprise/4.3/performance-testing/jmeter-samplers.md +++ b/content/en/archived-docs/corda-enterprise/4.3/performance-testing/jmeter-samplers.md @@ -51,7 +51,7 @@ When JMeter runs a test using such a sampler, the `setupTest` method is called o ## `EmptyFlowSampler` This sampler client has the class name `com.r3.corda.jmeter.EmptyFlowSampler` and starts the flow `com.r3.corda.enterprise.perftestcordapp.flows.EmptyFlow`. As the name suggests, the `call()` method of this flow is empty - it does not run any logic of its own. Invoking this flow goes through the whole overhead of invoking a flow via RPC without adding any additional flow work, and can therefore be used to measure the pure overhead of invoking a flow in a given set-up. -{{< figure alt="jmeter empty flow sampler" width=80% zoom="../resources/empty-flow-sampler.png" >}} +{{< figure alt="jmeter empty flow sampler" width=80% src="../resources/empty-flow-sampler.png" >}} This sampler client requires the following minimal set of properties: * `label`: A label for reporting results on this sampler - if in doubt what to put here, `${__samplername}` will fill in the sampler client classname. @@ -67,7 +67,7 @@ This sampler client has the classname `com.r3.corda.jmeter.CashIssueSampler` and `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueFlow`. This flow will self-issue 1.1 billion cash tokens on the node it is running on and store it in the vault. -{{< figure alt="jmeter cash issue sampler" width=80% zoom="../resources/cash-issue-sampler.png" >}} +{{< figure alt="jmeter cash issue sampler" width=80% src="../resources/cash-issue-sampler.png" >}} In addition to the common properties described above under `EmptyFlowSampler`, this sampler client also requires the following property: * `notaryName`: The X500 name of the notary that will be acceptable to transfer cash tokens issued via this sampler. Issuing tokens does not need to be notarised, and therefore invoking this sampler does not create traffic to the notary. However, the notary is stored as part of the cash state and must be valid to do anything else with the cash state, therefore this sampler will check the notary identity against the network parameters of the node. @@ -76,7 +76,7 @@ In addition to the common properties described above under `EmptyFlowSampler`, t This sampler client has the classname `com.r3.corda.jmeter.CashIssueAndPaySampler` and can start either the flow `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndPaymentFlow` or `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndpaymentNoSelection`, depending on its parameters. Either way, it issues 2 million dollars in tokens and then transfers the sum to a configurable other node, thus invoking the full vault access, peer-to-peer communication and notarisation cycle. -{{< figure alt="cash issue and pay sampler" width=80% zoom="../resources/cash-issue-and-pay-sampler.png" >}} +{{< figure alt="cash issue and pay sampler" width=80% src="../resources/cash-issue-and-pay-sampler.png" >}} In addition to the parameters required for the `CashIssueSampler`, this sampler client also requires the following properties: @@ -87,7 +87,7 @@ In addition to the parameters required for the `CashIssueSampler`, this sampler ## `CashPaySampler` The classname of this sampler client is `com.r3.corda.jmeter.CashPaySampler`. The `CashPaySampler` client issues cash once per run in its `setupTest` method, and then generates a transaction to pay 1 dollar `numberOfStatesPerTx` times to a specified party per sample, thus invoking the notary and the payee via P2P. This allows us to test performance with different numbers of states per transaction, and to eliminate issuance from each sample (unlike `CashIssueAndPaySampler`). -{{< figure alt="cash pay sampler" width=80% zoom="../resources/cash-pay-sampler.png" >}} +{{< figure alt="cash pay sampler" width=80% src="../resources/cash-pay-sampler.png" >}} In addition to the base requirements as in the `CashIssueSampler`, this sampler client requires the following properties: * `otherPartyName`: The Corda X500 name of the party receiving the payments. diff --git a/content/en/archived-docs/corda-enterprise/4.3/performance-testing/jmeter-testplans.md b/content/en/archived-docs/corda-enterprise/4.3/performance-testing/jmeter-testplans.md index cb406f50074..21dc991ad91 100644 --- a/content/en/archived-docs/corda-enterprise/4.3/performance-testing/jmeter-testplans.md +++ b/content/en/archived-docs/corda-enterprise/4.3/performance-testing/jmeter-testplans.md @@ -28,12 +28,12 @@ The testplan is a hierarchy of configuration elements. The only elements used in *Variables*, *Thread Groups*, *Samplers* and *Listeners*. Rather than creating a new testplan from scratch, it might a good idea to take a copy of one of the provided example test plans and modify that. -{{< figure alt="jmeter testplan" width=80% zoom="/en/jmeter-testplan.png" >}} +{{< figure alt="jmeter testplan" width=80% src="/en/jmeter-testplan.png" >}} A variables element defines key/value pairs that can be used in all following following elements instead of string literals. They can be referenced by using a `$` sign and curly braces, e.g. `${varName}`. -{{< figure alt="variables" width=80% zoom="/en/variables.png" >}} +{{< figure alt="variables" width=80% src="/en/variables.png" >}} A thread group collects a set of actions that form one step in the test plan. All elements within a thread group diff --git a/content/en/archived-docs/corda-enterprise/4.3/performance-testing/practical-considerations.md b/content/en/archived-docs/corda-enterprise/4.3/performance-testing/practical-considerations.md index 8eeba931bc1..91a7d579019 100644 --- a/content/en/archived-docs/corda-enterprise/4.3/performance-testing/practical-considerations.md +++ b/content/en/archived-docs/corda-enterprise/4.3/performance-testing/practical-considerations.md @@ -98,7 +98,7 @@ To collect the output of a JMeter performance run, we need to add listeners to t This listener just lists all the runs that have been completed, one run per row, stating the thread name, sampler label, the sample time in milliseconds, the result status and the latency in milliseconds, among other (usually less useful) fields. -{{< figure alt="jmeter results table" width=80% zoom="/en/jmeter-results-table.png" >}} +{{< figure alt="jmeter results table" width=80% src="/en/jmeter-results-table.png" >}} This view is particularly useful when trying out any changes (new flow, new sampler, new installation) to see if it is working at all. The potential outcomes are: @@ -127,7 +127,7 @@ This listener aggregates all the runs for each thread group and the whole test p It also allows plotting these statistics in basic charts and to save the results as a csv file. This is what we use for looking at the performance results on a day to day basis. -{{< figure alt="jmeter results aggregate" width=80% zoom="/en/jmeter-results-aggregate.png" >}} +{{< figure alt="jmeter results aggregate" width=80% src="/en/jmeter-results-aggregate.png" >}} This listener has one line for each sampler being run as part of the test plan, and a total line summing up/averaging the results for the whole test plan. diff --git a/content/en/archived-docs/corda-enterprise/4.3/performance-testing/running-jmeter-corda.md b/content/en/archived-docs/corda-enterprise/4.3/performance-testing/running-jmeter-corda.md index 30d85c157f2..7bbcef3c463 100644 --- a/content/en/archived-docs/corda-enterprise/4.3/performance-testing/running-jmeter-corda.md +++ b/content/en/archived-docs/corda-enterprise/4.3/performance-testing/running-jmeter-corda.md @@ -53,7 +53,7 @@ interactively either locally or remotely, and view results. The UI has a set of quickly create or load a testplan, control local or remote test runs, and clear any test results collected so far. The latter is particularly important when looking at averages, as old data might skew the results being looked at. -{{< figure alt="jmeter buttons" width=80% zoom="/en/jmeter-buttons.png" >}} +{{< figure alt="jmeter buttons" width=80% src="/en/jmeter-buttons.png" >}} The *clear current view* button only clears the data in the currently viewed output collector - if a test plan has several output listeners defined (as in the example above, we have *Aggregate Graph*, *Graph Results* and *View Results in Table*), diff --git a/content/en/archived-docs/corda-enterprise/4.4/performance-testing/introduction.md b/content/en/archived-docs/corda-enterprise/4.4/performance-testing/introduction.md index eab0879cfcb..87f6bf33010 100644 --- a/content/en/archived-docs/corda-enterprise/4.4/performance-testing/introduction.md +++ b/content/en/archived-docs/corda-enterprise/4.4/performance-testing/introduction.md @@ -115,7 +115,7 @@ measuring the throughput of a node, the test definition instructs all JMeter ser thus saturating the RPC handler and driving the node as hard as possible. The test typically e.g. issues cash on the node (no interaction with other nodes) or sends cash to a second node which requires sending P2P messages back and forth. -{{< figure alt="jmeter network overview" width=80% zoom="../resources/jmeter-network-overview.png" >}} +{{< figure alt="jmeter network overview" width=80% src="../resources/jmeter-network-overview.png" >}} ## Performance Tests diff --git a/content/en/archived-docs/corda-enterprise/4.4/performance-testing/jmeter-samplers.md b/content/en/archived-docs/corda-enterprise/4.4/performance-testing/jmeter-samplers.md index 54a51cf8923..d70460f3507 100644 --- a/content/en/archived-docs/corda-enterprise/4.4/performance-testing/jmeter-samplers.md +++ b/content/en/archived-docs/corda-enterprise/4.4/performance-testing/jmeter-samplers.md @@ -52,7 +52,7 @@ When JMeter runs a test using such a sampler, the `setupTest` method is called o ## `EmptyFlowSampler` This sampler client has the class name `com.r3.corda.jmeter.EmptyFlowSampler` and starts the flow `com.r3.corda.enterprise.perftestcordapp.flows.EmptyFlow`. As the name suggests, the `call()` method of this flow is empty - it does not run any logic of its own. Invoking this flow goes through the whole overhead of invoking a flow via RPC without adding any additional flow work, and can therefore be used to measure the pure overhead of invoking a flow in a given set-up. -{{< figure alt="jmeter empty flow sampler" width=80% zoom="../resources/empty-flow-sampler.png" >}} +{{< figure alt="jmeter empty flow sampler" width=80% src="../resources/empty-flow-sampler.png" >}} This sampler client requires the following minimal set of properties: * `label`: A label for reporting results on this sampler - if in doubt what to put here, `${__samplername}` will fill in the sampler client classname. @@ -68,7 +68,7 @@ This sampler client has the classname `com.r3.corda.jmeter.CashIssueSampler` and `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueFlow`. This flow will self-issue 1.1 billion cash tokens on the node it is running on and store it in the vault. -{{< figure alt="jmeter cash issue sampler" width=80% zoom="../resources/cash-issue-sampler.png" >}} +{{< figure alt="jmeter cash issue sampler" width=80% src="../resources/cash-issue-sampler.png" >}} In addition to the common properties described above under `EmptyFlowSampler`, this sampler client also requires the following property: * `notaryName`: The X500 name of the notary that will be acceptable to transfer cash tokens issued via this sampler. Issuing tokens does not need to be notarised, and therefore invoking this sampler does not create traffic to the notary. However, the notary is stored as part of the cash state and must be valid to do anything else with the cash state, therefore this sampler will check the notary identity against the network parameters of the node. @@ -77,7 +77,7 @@ In addition to the common properties described above under `EmptyFlowSampler`, t This sampler client has the classname `com.r3.corda.jmeter.CashIssueAndPaySampler` and can start either the flow `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndPaymentFlow` or `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndpaymentNoSelection`, depending on its parameters. Either way, it issues 2 million dollars in tokens and then transfers the sum to a configurable other node, thus invoking the full vault access, peer-to-peer communication and notarisation cycle. -{{< figure alt="cash issue and pay sampler" width=80% zoom="../resources/cash-issue-and-pay-sampler.png" >}} +{{< figure alt="cash issue and pay sampler" width=80% src="../resources/cash-issue-and-pay-sampler.png" >}} In addition to the parameters required for the `CashIssueSampler`, this sampler client also requires the following properties: @@ -88,7 +88,7 @@ In addition to the parameters required for the `CashIssueSampler`, this sampler ## `CashPaySampler` The classname of this sampler client is `com.r3.corda.jmeter.CashPaySampler`. The `CashPaySampler` client issues cash once per run in its `setupTest` method, and then generates a transaction to pay 1 dollar `numberOfStatesPerTx` times to a specified party per sample, thus invoking the notary and the payee via P2P. This allows us to test performance with different numbers of states per transaction, and to eliminate issuance from each sample (unlike `CashIssueAndPaySampler`). -{{< figure alt="cash pay sampler" width=80% zoom="../resources/cash-pay-sampler.png" >}} +{{< figure alt="cash pay sampler" width=80% src="../resources/cash-pay-sampler.png" >}} In addition to the base requirements as in the `CashIssueSampler`, this sampler client requires the following properties: * `otherPartyName`: The Corda X500 name of the party receiving the payments. diff --git a/content/en/archived-docs/corda-enterprise/4.4/performance-testing/jmeter-testplans.md b/content/en/archived-docs/corda-enterprise/4.4/performance-testing/jmeter-testplans.md index fd5eebc9270..172df04bd05 100644 --- a/content/en/archived-docs/corda-enterprise/4.4/performance-testing/jmeter-testplans.md +++ b/content/en/archived-docs/corda-enterprise/4.4/performance-testing/jmeter-testplans.md @@ -29,12 +29,12 @@ The testplan is a hierarchy of configuration elements. The only elements used in *Variables*, *Thread Groups*, *Samplers* and *Listeners*. Rather than creating a new testplan from scratch, it might a good idea to take a copy of one of the provided example test plans and modify that. -{{< figure alt="jmeter testplan" width=80% zoom="../resources/jmeter-testplan.png" >}} +{{< figure alt="jmeter testplan" width=80% src="../resources/jmeter-testplan.png" >}} A variables element defines key/value pairs that can be used in all following elements instead of string literals. They can be referenced by using a `$` sign and curly braces, e.g. `${varName}`. -{{< figure alt="variables" width=80% zoom="../resources/variables.png" >}} +{{< figure alt="variables" width=80% src="../resources/variables.png" >}} A thread group collects a set of actions that form one step in the test plan. All elements within a thread group diff --git a/content/en/archived-docs/corda-enterprise/4.4/performance-testing/practical-considerations.md b/content/en/archived-docs/corda-enterprise/4.4/performance-testing/practical-considerations.md index ddf69f0eef8..c4598dc2879 100644 --- a/content/en/archived-docs/corda-enterprise/4.4/performance-testing/practical-considerations.md +++ b/content/en/archived-docs/corda-enterprise/4.4/performance-testing/practical-considerations.md @@ -98,7 +98,7 @@ To collect the output of a JMeter performance run, we need to add listeners to t This listener just lists all the runs that have been completed, one run per row, stating the thread name, sampler label, the sample time in milliseconds, the result status and the latency in milliseconds, among other (usually less useful) fields. -{{< figure alt="jmeter results table" width=80% zoom="../resources/jmeter-results-table.png" >}} +{{< figure alt="jmeter results table" width=80% src="../resources/jmeter-results-table.png" >}} This view is particularly useful when trying out any changes (new flow, new sampler, new installation) to see if it is working at all. The potential outcomes are: @@ -127,7 +127,7 @@ This listener aggregates all the runs for each thread group and the whole test p It also allows plotting these statistics in basic charts and to save the results as a csv file. This is what we use for looking at the performance results on a day-to-day basis. -{{< figure alt="jmeter results aggregate" width=80% zoom="../resources/jmeter-results-aggregate.png" >}} +{{< figure alt="jmeter results aggregate" width=80% src="../resources/jmeter-results-aggregate.png" >}} This listener has one line for each sampler being run as part of the test plan, and a total line summing up/averaging the results for the whole test plan. diff --git a/content/en/archived-docs/corda-enterprise/4.4/performance-testing/running-jmeter-corda.md b/content/en/archived-docs/corda-enterprise/4.4/performance-testing/running-jmeter-corda.md index 6daec4ab1e1..b0a84a3aef6 100644 --- a/content/en/archived-docs/corda-enterprise/4.4/performance-testing/running-jmeter-corda.md +++ b/content/en/archived-docs/corda-enterprise/4.4/performance-testing/running-jmeter-corda.md @@ -55,7 +55,7 @@ interactively either locally or remotely, and view results. The UI has a set of quickly create or load a testplan, control local or remote test runs, and clear any test results collected so far. The latter is particularly important when looking at averages, as old data might skew the results being looked at. -{{< figure alt="jmeter buttons" width=80% zoom="../resources/jmeter-buttons.png" >}} +{{< figure alt="jmeter buttons" width=80% src="../resources/jmeter-buttons.png" >}} The *clear current view* button only clears the data in the currently viewed output collector - if a test plan has several output listeners defined (as in the example above, we have *Aggregate Graph*, *Graph Results* and *View Results in Table*), any collector not currently selected is not affected. *Clear all data* will clear the results from all collectors. diff --git a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/introduction.md b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/introduction.md index 5255bce9bfc..15969c4f25f 100644 --- a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/introduction.md +++ b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/introduction.md @@ -109,7 +109,7 @@ The driving app sits outside the network and connects to the JMeter servers thro measuring the throughput of a node, the test definition instructs all JMeter servers to open RPC connections to one node, thus saturating the RPC handler and driving the node as hard as possible. The test might invoke a flow that can be completed locally (for example, cash issuance) or it might require exchanging P2P messages with other nodes (for example, cash payment). -{{< figure alt="jmeter network overview" width=80% zoom="../resources/jmeter-network-overview.png" >}} +{{< figure alt="jmeter network overview" width=80% src="../resources/jmeter-network-overview.png" >}} ## Performance Tests diff --git a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/jmeter-samplers.md b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/jmeter-samplers.md index a75c4bb648a..bca6a7b0520 100644 --- a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/jmeter-samplers.md +++ b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/jmeter-samplers.md @@ -66,7 +66,7 @@ server, not the client machine. * `minimumNodePlatformVersion`: the minimum platform version that the JMeter client will require from the Corda nodes. It defaults to 4, which can be used to test with Corda 4.0 nodes or later. * `username`: the RPC user name of the Corda node. * `password`: the RPC password of the Corda node. -{{< figure alt="empty flow sampler" width=80% zoom="../resources/empty-flow-sampler.png" >}} +{{< figure alt="empty flow sampler" width=80% src="../resources/empty-flow-sampler.png" >}} * `CashIssueSampler`: this sampler client has the class name `com.r3.corda.jmeter.CashIssueSampler` and starts the flow `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueFlow`. This flow self-issues 1.1 billion cash tokens on the node it is running on, and stores it in the vault. In addition to the common properties described for `EmptyFlowSampler` above, this sampler client also requires: * `notaryName`: the X500 name of the notary that is acceptable to transfer cash tokens issued via this sampler. Issuing tokens does not need to be notarised, and therefore invoking this sampler does not create traffic to the notary. However, the notary is stored as part of the cash state and must be valid to do anything else with the cash state, therefore this sampler checks the notary identity against the network parameters of the node. * `CashIssueAndPaySampler`: this sampler client has the classname `com.r3.corda.jmeter.CashIssueAndPaySampler` and, depending on its parameters, it can start either of these flows - `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndPaymentFlow` or `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndpaymentNoSelection`. Either way it issues 2 million dollars in tokens and then transfers the sum to a configurable other node, thus invoking the full vault access, peer-to-peer communication and notarisation cycle. In addition to the parameters required for `CashIssueSampler`, this sampler also requires: diff --git a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/jmeter-testplans.md b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/jmeter-testplans.md index db49c42498b..a0e8fbda5a9 100644 --- a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/jmeter-testplans.md +++ b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/jmeter-testplans.md @@ -25,12 +25,12 @@ The testplan is a hierarchy of configuration elements. The only elements used in *Variables*, *Thread Groups*, *Samplers* and *Listeners*. Rather than creating a new testplan from scratch, it might a good idea to take a copy of one of the provided example test plans and modify that. -{{< figure alt="jmeter testplan" width=80% zoom="../resources/jmeter-testplan.png" >}} +{{< figure alt="jmeter testplan" width=80% src="../resources/jmeter-testplan.png" >}} A variables element defines key/value pairs that can be used in all following following elements instead of string literals. They can be referenced by using a `$` sign and curly braces, e.g. `${varName}`. -{{< figure alt="variables" width=80% zoom="../resources/variables.png" >}} +{{< figure alt="variables" width=80% src="../resources/variables.png" >}} A thread group collects a set of actions that form one step in the test plan. All elements within a thread group diff --git a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/performance-results.md b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/performance-results.md index 13d4e5b3798..124164f61f6 100644 --- a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/performance-results.md +++ b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/performance-results.md @@ -40,7 +40,7 @@ the time of Corda Enterprise Edition 4 release). This is with each node running running **Microsoft SQL Server**. Similar results were obtained against the other supported databases. -{{< figure alt="ce4 comparison chart" width=80% zoom="/en/images/ce4-comparison-chart.png" >}} +{{< figure alt="ce4 comparison chart" width=80% src="/en/images/ce4-comparison-chart.png" >}} Figure 1 @@ -52,7 +52,7 @@ varies with the number of those payments combined together. This can be useful be a technique for even greater throughput. -{{< figure alt="states per second" width=80% zoom="/en/images/states-per-second.png" >}} +{{< figure alt="states per second" width=80% src="/en/images/states-per-second.png" >}} Figure 2 @@ -65,7 +65,7 @@ of Figure 3 were achieved using Corda Enterprise 3.0 on **Microsoft Azure** virt with minimal latency between the node VM and the database server VM. -{{< figure alt="comparison chart" width=80% zoom="/en/images/comparison-chart.png" >}} +{{< figure alt="comparison chart" width=80% src="/en/images/comparison-chart.png" >}} Figure 3 @@ -303,7 +303,7 @@ All these machines were 24 core (48 hyper-threads), based on 2x Intel Xeon E5-26 The first test performed was focused on the latency aspect. Load was generated from a single client initialised in a machine that was separate from the ones hosting the Corda nodes and their databases. The load consisted of a pre-defined number of flows (400) that were executed one after the other sequentially. Each one of those flows was initiated on the central exchange node, which was responsible for collecting signatures from all the parties involved and for finalising the transaction. Each of those flows performed a swap of two states between every pair of nodes, thus leading to a Corda transaction with 10 input and 10 output states. During the test setup, the necessary amount of states was initially issued and each one of those states would be swapped once during the test. In order to also measure the impact of transaction resolution, during the test setup each of these states was transferred bilaterally between the nodes in each pair ten times, thus generating a backchain of depth 10. This meant that during every Corda transaction, each node would have to resolve the backchain of the states belonging to the other pairs - so each node would have to resolve 80 states (8 nodes x 10 states each). In order to also measure the scaling with regard to the number of nodes, the exact same test was repeated with a varying number of participants, starting from 4 nodes and going up to 10. The test was also repeated three times with Corda Enterprise versions 4.3, 4.4, and 4.5. The goal was to isolate the benefits from bulk transaction resolution, introduced in version 4.4, and parallelised flows (`CollectSignaturesFlow` / `FinalityFlow`), introduced in version 4.5. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average latency of the flow that performed the asset swap in milliseconds. -{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.3 shows an exponential increase in the latency of the flow as the number of nodes that participate in the transaction is increased. This can be attributed to the following two reasons. Firstly, during the tests the exchange node was performing the `CollectSignaturesFlow` and `FinalityFlow` flows sequentially across the involved nodes, so the more nodes these flows had to iterate over, the more time it took. Secondly, these flows have the capability to trigger the execution of transaction resolution if they identify states for which the node is missing the provenance chain. In Corda Enterprise Edition 4.3, transaction resolution is not performed in bulk - it is performed one state at a time. As a result, every additional node causes a significant amount of extra work to be done. @@ -314,7 +314,7 @@ The main observations from the tests follow below: The second test was focused on the throughput aspect. Load was generated from multiple clients initialised on the machines that were hosting the Corda nodes, which were acting as JMeter servers orchestrated by a JMeter client running on a separate machine. The goal was to saturate the participating Corda nodes and to prevent the single client from becoming the bottleneck. During the test setup, each client issued one state to every node. Each client was then performing one flow at a time, swapping these states between the participating nodes. No backchain was generated as part of this test. As a result, the test was executed only between Corda Enterprise Edition 4.3 and Corda Enterprise Edition 4.5, and with a varying number of nodes ranging from 2 up to 10. Each of the machines driving the load was using 120 concurrent clients, which summed up to 480 concurrent clients in total. Additional measurements were performed with a varying number of clients, in order to ensure that this was the optimal number of clients to saturate the nodes without overloading them. Since the throughput was different depending on the number of participating nodes, the total number of requests was also adjusted accordingly in order to get roughly the same total duration of approximately 20 minutes. In all the scenarios, it was confirmed that the nodes had reached a stable state when the test ended. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average throughput measured in the number of flows completed per second. -{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.5 can achieve a significantly higher throughput when compared to Corda Enterprise Edition 4.3. This can be attributed to the following factors: @@ -336,9 +336,9 @@ Five different variations were tested, as follows: The purpose of this last test was to investigate the effects of these options in both throughput and latency because some of these options introduce trade-offs between these two aspects. To this end, the tests described earlier in this analysis were repeated using the variations listed above. For the latency measurements, 10 nodes were used because, thanks to the low load, there was no expectation for any big interference between nodes on the same machine. For the throughput measurements, only 4 nodes were used in order to avoid any interference between nodes on the same machine due to the high load. The results are shown in the diagrams below - the *x* axis contains the variations used, and the *y* axis shows the average throughput and latency achieved with each variation along with error bars indicating the standard deviation. -{{< figure alt="CE 4.5 variants latency comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_latency.png" >}} +{{< figure alt="CE 4.5 variants latency comparison chart" width=80% src="../resources/performance-testing/4-5_variants_latency.png" >}} -{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_throughput.png" >}} +{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% src="../resources/performance-testing/4-5_variants_throughput.png" >}} The main observations from the test are as follows: * Disabling compression leads to lower throughput and higher latency. This is expected because compression introduces a trade-off between CPU and network bandwidth utilisation and in most cases the network would prove to be a bigger bottleneck. diff --git a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/practical-considerations.md b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/practical-considerations.md index acc6a1389b7..9dcb6264b1d 100644 --- a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/practical-considerations.md +++ b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/practical-considerations.md @@ -94,7 +94,7 @@ To collect the output of a JMeter performance run, we need to add listeners to t This listener just lists all the runs that have been completed, one run per row, stating the thread name, sampler label, the sample time in milliseconds, the result status and the latency in milliseconds, among other (usually less useful) fields. -{{< figure alt="jmeter results table" width=80% zoom="../resources/jmeter-results-table.png" >}} +{{< figure alt="jmeter results table" width=80% src="../resources/jmeter-results-table.png" >}} This view is particularly useful when trying out any changes (new flow, new sampler, new installation) to see if it is working at all. The potential outcomes are: @@ -123,7 +123,7 @@ This listener aggregates all the runs for each thread group and the whole test p It also allows plotting these statistics in basic charts and to save the results as a csv file. This is what we use for looking at the performance results on a day to day basis. -{{< figure alt="jmeter results aggregate" width=80% zoom="../resources/jmeter-results-aggregate.png" >}} +{{< figure alt="jmeter results aggregate" width=80% src="../resources/jmeter-results-aggregate.png" >}} This listener has one line for each sampler being run as part of the test plan, and a total line summing up/averaging the results for the whole test plan. diff --git a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/r3-performance-runs.md b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/r3-performance-runs.md index 32ea741565f..69a0136b200 100644 --- a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/r3-performance-runs.md +++ b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/r3-performance-runs.md @@ -32,7 +32,7 @@ The performance network sits behind a firewall that allows incoming connections within the network can connect to each other on a range of ports (Corda Remote Procedure Call (RPC), Corda peer to peer connection (P2P) and JDBC connections to various database servers are all allowed). -{{< figure alt="performance cluster" width=80% zoom="../resources/performance-cluster.png" >}} +{{< figure alt="performance cluster" width=80% src="../resources/performance-cluster.png" >}} A Corda JMeter server instance is running on all 4 nodes and on the notary server. The JMeter client connects to the JMeter server instances via SSH tunnels. As the JMeter servers run within the firewalled network, they are free to diff --git a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/running-jmeter-corda.md b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/running-jmeter-corda.md index 7fbb3c157ef..69cd7b1c43e 100644 --- a/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/running-jmeter-corda.md +++ b/content/en/archived-docs/corda-enterprise/4.5/enterprise/performance-testing/running-jmeter-corda.md @@ -54,7 +54,7 @@ interactively either locally or remotely, and view results. The UI has a set of quickly create or load a testplan, control local or remote test runs, and clear any test results collected so far. The latter is particularly important when looking at averages, as old data might skew the results being looked at. -{{< figure alt="jmeter buttons" width=80% zoom="../resources/jmeter-buttons.png" >}} +{{< figure alt="jmeter buttons" width=80% src="../resources/jmeter-buttons.png" >}} The *clear current view* button only clears the data in the currently viewed output collector - if a test plan has several output listeners defined (as in the example above, we have *Aggregate Graph*, *Graph Results* and *View Results in Table*), any collector not currently selected is not affected. *Clear all data* will clear the results from all collectors. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/api-core-types.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/api-core-types.md index 78d1c04fb40..82e6bb8db24 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/api-core-types.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/api-core-types.md @@ -41,11 +41,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="./resources/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="./resources/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="./resources/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="./resources/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/contract-irs.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/contract-irs.md index 837496e4cad..4ea2f877171 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/contract-irs.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/contract-irs.md @@ -45,7 +45,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="./resources/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="./resources/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapp-advanced-concepts.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapp-advanced-concepts.md index 1814bfdb596..0ced778395a 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapp-advanced-concepts.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapp-advanced-concepts.md @@ -71,7 +71,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="./resources/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="./resources/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/api-flows.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/api-flows.md index 0f39ac418f6..74b4801cf07 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/api-flows.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/api-flows.md @@ -62,7 +62,7 @@ In our flow, the Initiator flow class will be doing the majority of the work, th We can visualize the work performed by initiator as follows: -{{< figure alt="flow overview" width=80% zoom="../resources/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="../resources/flow-overview.png" >}} ## Responder diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/api-states.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/api-states.md index 81316c791f8..c89bc1ff826 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/api-states.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/api-states.md @@ -62,7 +62,7 @@ the total amount held that is important, rather than the actual units held. We can picture the hierarchy as follows: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/cordapp-overview.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/cordapp-overview.md index 221dcd9580d..d0265dbf3d7 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/cordapp-overview.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/cordapp-overview.md @@ -18,7 +18,7 @@ CorDapps (Corda Distributed Applications) are distributed applications that run CorDapp is to allow nodes to reach agreement on updates to the ledger. They achieve this goal by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="../resources/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="../resources/node-diagram.png" >}} {{< note >}} When designing your CorDapp, you may want to consider using the [CorDapp Design Language](../../../../../tools/cdl/cdl-overview.md) to structure and organise your designs. This can be especially helpful for complex CorDapps. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/deterministic-jvm.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/deterministic-jvm.md index 20426bd5d0f..9bb0b440b9c 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/deterministic-jvm.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/deterministic-jvm.md @@ -75,7 +75,7 @@ severity `ERROR` will prevent execution. The sandbox has a configuration that applies to the execution of a specific runnable. This configuration, on a higher level, contains a set of rules, definition providers and emitters. -{{< figure alt="djvm overview" width=80% zoom="../resources/djvm-overview.png" >}} +{{< figure alt="djvm overview" width=80% src="../resources/djvm-overview.png" >}} The set of rules is what defines the constraints posed on the runtime environment. A rule can act on three different levels, namely on a type-, member- or instruction-level. The set of rules get processed and validated by the `RuleValidator` prior to execution. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/upgrading-cordapps.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/upgrading-cordapps.md index 26d8cac16d0..15d7f56493f 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/upgrading-cordapps.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/cordapps/upgrading-cordapps.md @@ -69,7 +69,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="../resources/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="../resources/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/financial-model.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/financial-model.md index c2c9db0ae38..2fc57cec862 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/financial-model.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/financial-model.md @@ -90,6 +90,6 @@ countable (in cents), barrels of West Texas crude are fungible and countable (oi container), shares of the same class in a specific company are fungible and countable, and so on. The following diagram illustrates the complete Contract State hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Note there are currently two packages, a core library and a finance model specific library. Developers may re-use or extend the Finance types directly or write their own by extending the base types from the Core library. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/health-survey.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/health-survey.md index 20612ac7551..6c16a870cdd 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/health-survey.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/health-survey.md @@ -116,7 +116,7 @@ The Corda Health Survey currently does not support testing RPC communication if The tool generates the archive of the collected files in the same directory it is ran in. The names are in the format: `report-date-time.zip` -{{< figure alt="health survey photo" width=80% zoom="resources/health-survey-photo.png" >}} +{{< figure alt="health survey photo" width=80% src="resources/health-survey-photo.png" >}} ## Deployment health check diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-consensus.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-consensus.md index ae02a4dd741..19f6da3df97 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-consensus.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-consensus.md @@ -53,7 +53,7 @@ transferring us a treasury bond. We can only be sure that the bond transfer is v The only way to be sure of both conditions is to walk the transaction’s chain. We can visualize this process as follows: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a given party may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer(s). The transaction proposer(s) will always have the full transaction chain, since they would have requested it when @@ -70,7 +70,7 @@ proposals: This is a problem because, although both transactions will achieve validity consensus, Bob has managed to “double-spend” his USD to get double the amount of GBP and EUR. We can visualize this as follows: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-contracts.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-contracts.md index 8e98321dab2..b5ddba61c81 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-contracts.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-contracts.md @@ -43,7 +43,7 @@ valid We can picture this situation as follows: -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code has access to the full capabilities of the language, including: diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-djvm.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-djvm.md index 3028df6a270..c42b49ccf8e 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-djvm.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-djvm.md @@ -83,7 +83,7 @@ severity `ERROR` will prevent execution. The sandbox has a configuration that applies to the execution of a specific runnable. This configuration, on a higher level, contains a set of rules, definition providers and emitters. -{{< figure alt="djvm overview" width=80% zoom="/en/images/djvm-overview.png" >}} +{{< figure alt="djvm overview" width=80% src="/en/images/djvm-overview.png" >}} The set of rules is what defines the constraints posed on the runtime environment. A rule can act on three different levels, namely on a type-, member- or instruction-level. The set of rules get processed and validated by the `RuleValidator` prior to execution. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-ecosystem.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-ecosystem.md index 97367428b9c..fb0da36004d 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-ecosystem.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-ecosystem.md @@ -29,7 +29,7 @@ title: Network A Corda network is a peer-to-peer network of **nodes**. Each node represents a legal entity, and each runs the Corda software (an instance of Corda and one or more Corda applications, known as **CorDapps**). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} All communication between nodes is point-to-point and encrypted using transport-layer security. This means that data is shared only on a need-to-know basis. There are **no global broadcasts**. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-flows.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-flows.md index d10647d923c..ef7c5557864 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-flows.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-flows.md @@ -36,7 +36,7 @@ what order. Here is a visualisation of the process of agreeing a simple ledger update between Alice and Bob: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -45,7 +45,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is the sequence of flow steps involved in the simple ledger update above: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-ledger.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-ledger.md index 007ccb9c1e8..b5ba1241263 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-ledger.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-ledger.md @@ -37,7 +37,7 @@ The facts that a node knows about are those that it is involved with. For exampl Example: A network with five nodes, where each numbered circle on an intersection represents a fact shared between two or more nodes. -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} The preceding Venn diagram represents 5 nodes (Alice, Bob, Carl, Demi and Ed) as sets. Where the sets overlap are shared facts, such as those known by both Alice and Bob (1 and 7). Notably, in this Venn diagram, Alice only shares facts with Bob. Alice does not share facts with any of Carl, Demi or Ed. @@ -61,7 +61,7 @@ In the previous diagram, we could see that although Carl, Demi and Ed are aware You can think of this vault as being a database or simple table. -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} Where the rows are shared between nodes (facts 1 and 7 in this example), these are shared facts. Corda guarantees that whenever one of these facts is shared by multiple nodes on the network, it evolves in lockstep in the database of every node that is aware of it. This means that Alice and Bob will both see an **exactly identical version** of shared facts 1 and 7. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-node.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-node.md index 19dee7f4eeb..8096ad9ba58 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-node.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-node.md @@ -37,7 +37,7 @@ CorDapps. We can visualize the node’s internal architecture as follows: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: * A persistence layer for storing data diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-states.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-states.md index f257f07bf46..afebcc26b15 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-states.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-states.md @@ -36,7 +36,7 @@ identity information…). For example, the following state represents an IOU - an agreement that Alice owes Bob an amount X: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} Specifically, this state represents an IOU of £10 from Alice to Bob. As well as any information about the fact itself, the state also contains a reference to the *contract* that governs @@ -53,14 +53,14 @@ historic. This sequence of state replacements gives us a full view of the evolution of the shared fact over time. We can picture this situation as follows: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a *vault* - a database where it tracks all the current and historic states that it is aware of, and which it considers to be relevant to itself: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} We can think of the ledger from each node’s point of view as the set of all the current (i.e. non-historic) states that it is aware of. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-tearoffs.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-tearoffs.md index f8644e7a5a1..7ef096b0912 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-tearoffs.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-tearoffs.md @@ -58,7 +58,7 @@ reveal the content of low-entropy hashed values (i.e., a single-word text attach After computing the leaves, each Merkle tree is built in the normal way by hashing the concatenation of nodes’ hashes below the current one together. It’s visible on the example image below, where `H` denotes sha256 function, “+” - concatenation. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} The transaction has three input states, two output states, two commands, one attachment, a notary and a time-window. Notice that if a tree is not a full binary tree, leaves are padded to the nearest power of 2 with zero hash (since finding a pre-image of sha256(x) == 0 is hard computational task) - marked light @@ -77,7 +77,7 @@ Let’s assume that only the first command should be visible to an Oracle. We sh the commands requiring a signature from this oracle should be visible to the oracle entity, but not the rest. Here is how this filtered transaction will be represented in the Merkle tree structure. -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} Blue nodes and `H(c2)` are provided to the Oracle service, while the black ones are omitted. `H(c2)` is required, so that the Oracle can compute `H(commandData)` without being to able to see the second command, but at the same time ensuring `CommandData1` is part of the transaction. It is highlighted that all signers are visible, so as to have a @@ -93,4 +93,4 @@ apart from input states, time-window and the notary information. This data is en input states should be checked for double-spending, if the time-window is valid and if this transaction should be notarised by this notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-time-windows.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-time-windows.md index d969bdf75c7..cc963f59163 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-time-windows.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-time-windows.md @@ -53,7 +53,7 @@ For this reason, times in transactions are specified as time *windows*, not abso there can never be “true time”, only an approximation of it. Time windows can be open-ended (i.e. specify only one of “before” and “after”) or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} In this way, we express the idea that the *true value* of the fact “the current time” is actually unknowable. Even when both a before and an after time are included, the transaction could have occurred at any point within that time-window. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-transactions.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-transactions.md index d630a638d59..eb9385c1332 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-transactions.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-transactions.md @@ -39,7 +39,7 @@ single link in the state sequences seen in [States](key-concepts-states.md). Here is an example of an update transaction, with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type: * They can include many different state types (states may represent cash or bonds, for example) @@ -66,7 +66,7 @@ These input states references are a combination of: This situation can be illustrated as follows: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} These input state references link transactions together over time, forming what is known as a *transaction chain*. ## Committing transactions @@ -74,14 +74,14 @@ These input state references link transactions together over time, forming what Initially, a transaction is just a **proposal** to update the ledger. It represents the future state of the ledger that is desired by the transaction builders: -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To become reality, the transaction must receive signatures from all of the *required signers* (see **Commands**, below). Each required signer appends their signature to the transaction to indicate that they approve the proposal: -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If all of the required signatures are gathered, the transaction becomes committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions @@ -128,7 +128,7 @@ This transaction comprises two commands: a settlement command which reduces the has two supporting attachments, and will only be notarised by NotaryClusterA if the notary pool receives it within the specified time-window. This transaction would look as follows: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -156,7 +156,7 @@ listed in the commands, we get the list of the transaction’s required signers. We can visualize this situation as follows: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-vault.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-vault.md index 307bdece9fa..8ccce7d0289 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-vault.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/key-concepts-vault.md @@ -65,7 +65,7 @@ The vault supports the management of data in both authoritative (“on-ledger” The following diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} Note the following: diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/network/azure-vm.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/network/azure-vm.md index 5e4d3cbfd78..0bc3aeaa9a2 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/network/azure-vm.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/network/azure-vm.md @@ -44,7 +44,7 @@ Define the basic parameters which will be used to pre-configure your Corda nodes * **Resource group**: Choose to ‘Create new’ and provide a useful name of your choice * **Location**: Select the geographical location physically closest to you -{{< figure alt="azure multi node step1" width=80% zoom="../resources/azure_multi_node_step1.png" >}} +{{< figure alt="azure multi node step1" width=80% src="../resources/azure_multi_node_step1.png" >}} Click ‘OK’ STEP 2: Network Size and Performance @@ -58,7 +58,7 @@ Define the number of Corda nodes in your network and the size of VM. * **Storage performance**: Leave as ‘Standard’ * **Virtual machine size**: The size of the VM is automatically adjusted to suit the number of participant nodes selected. It is recommended to use the suggested values -{{< figure alt="azure multi node step2" width=80% zoom="../resources/azure_multi_node_step2.png" >}} +{{< figure alt="azure multi node step2" width=80% src="../resources/azure_multi_node_step2.png" >}} Click ‘OK’ STEP 3: Corda Specific Options @@ -69,14 +69,14 @@ Define the version of Corda you want on your nodes and the type of notary. * **Corda version (as seen in Maven Central)**: Select the version of Corda you want your nodes to use from the drop down list. The version numbers can be seen in [Maven Central](http://repo1.maven.org/maven2/net/corda/corda/), for example 0.11.0 * **Notary type**: Select either ‘Non Validating’ (notary only checks whether a state has been previously used and marked as historic) or ‘Validating’ (notary performs transaction verification by seeing input and output states, attachments and other transaction information). More information on notaries can be found [here](https://vimeo.com/album/4555732/video/214138458) -{{< figure alt="azure multi node step3" width=80% zoom="../resources/azure_multi_node_step3.png" >}} +{{< figure alt="azure multi node step3" width=80% src="../resources/azure_multi_node_step3.png" >}} Click ‘OK’ STEP 4: Summary A summary of your selections is shown. -{{< figure alt="azure multi node step4" width=80% zoom="../resources/azure_multi_node_step4.png" >}} +{{< figure alt="azure multi node step4" width=80% src="../resources/azure_multi_node_step4.png" >}} Click ‘OK’ for your selection to be validated. If everything is ok you will see the message ‘Validation passed’ Click ‘OK’ @@ -91,7 +91,7 @@ Once deployed click ‘Resources Groups’, select the resource group you define The Network Map Service node is suffixed nm0. The Notary node is suffixed not0. Your Corda participant nodes are suffixed node0, node1, node2 etc. Note down the **Public IP address** for your Corda nodes. You will need these to connect to UI screens via your web browser: -{{< figure alt="azure ip" width=80% zoom="../resources/azure_ip.png" >}} +{{< figure alt="azure ip" width=80% src="../resources/azure_ip.png" >}} ## Using the Yo! CorDapp @@ -133,7 +133,7 @@ where (public IP address) is the public IP address of one of your Corda nodes on You will now see the Yo! CorDapp web interface: -{{< figure alt="Yo web ui" width=80% zoom="../resources/Yo_web_ui.png" >}} +{{< figure alt="Yo web ui" width=80% src="../resources/Yo_web_ui.png" >}} * **Sending a Yo message via the web interface** @@ -155,7 +155,7 @@ An easy way to see the Legal Names of Corda nodes on the network is to use the p http://(public IP address):(port)/api/yo/peers ``` -{{< figure alt="yo peers2" width=80% zoom="../resources/yo_peers2.png" >}} +{{< figure alt="yo peers2" width=80% src="../resources/yo_peers2.png" >}} * **Viewing Yo messages** @@ -165,7 +165,7 @@ To see Yo! messages sent to a particular node open a browser window and browse t http://(public IP address):(port)/api/yo/yos ``` -{{< figure alt="azure yos" width=80% zoom="../resources/azure_yos.png" >}} +{{< figure alt="azure yos" width=80% src="../resources/azure_yos.png" >}} ## Viewing logs @@ -186,8 +186,8 @@ And navigate to the following directory for system logs (syslog): You can open log files with any text editor. -{{< figure alt="azure vm 10 49" width=80% zoom="../resources/azure_vm_10_49.png" >}} -{{< figure alt="azure syslog" width=80% zoom="../resources/azure_syslog.png" >}} +{{< figure alt="azure vm 10 49" width=80% src="../resources/azure_vm_10_49.png" >}} +{{< figure alt="azure syslog" width=80% src="../resources/azure_syslog.png" >}} ## Next Steps diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/network/cipher-suites.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/network/cipher-suites.md index a1d49decc3f..96db3b8aac7 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/network/cipher-suites.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/network/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates](permissioning.md)): -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/network/permissioning.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/network/permissioning.md index 07bb67d63b3..fdeb946041e 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/network/permissioning.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/network/permissioning.md @@ -42,7 +42,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node-explorer.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node-explorer.md index c215f442033..615872bf128 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node-explorer.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node-explorer.md @@ -47,7 +47,7 @@ Run the installer on your machine in the way you would any other app. You can access any node with Node Explorer using the node's login credentials. If you are accessing a local node, or a remote node that is not protected with SSH, you can use the node's RPC login details. To access a remote node, protected by SSH, you also need the relevant port, username, and password. -{{< figure alt="login" width=80% zoom="resources/node-explorer/node-explorer-ssh-login.png" >}} +{{< figure alt="login" width=80% src="resources/node-explorer/node-explorer-ssh-login.png" >}} **To log in to a local or remote node without SSH credentials:** @@ -63,7 +63,7 @@ You can find this address by accessing your node through the command line - you {{< /note >}} -{{< figure alt="RPC connection address" width=80% zoom="resources/node-explorer/node-explorer-cl.png" >}} +{{< figure alt="RPC connection address" width=80% src="resources/node-explorer/node-explorer-cl.png" >}} 4. In the **Username** and **Password** fields, enter the username and password you would use to access your node. @@ -92,7 +92,7 @@ The Node Explorer dashboard is shown. If you are connecting to this node for the Before you can start using Node Explorer to execute flows, you need to add the directory of your CorDapps. This enables the explorer to discover the required parameters for each flow. -{{< figure alt="Settings" width=80% zoom="resources/node-explorer/node-explorer-settings.png" >}} +{{< figure alt="Settings" width=80% src="resources/node-explorer/node-explorer-settings.png" >}} To add your CorDapp directory: @@ -111,7 +111,7 @@ The dashboard is the first screen that opens when you [start Node Explorer](#acc On the dashboard, you can see two panels with details and diagnostics of two aspects of your node - **Node information** and **Network Parameters**. -{{< figure alt="Dashboard" width=80% zoom="resources/node-explorer/node-explorer-dash.png" >}} +{{< figure alt="Dashboard" width=80% src="resources/node-explorer/node-explorer-dash.png" >}} In the **Node information** panel you can see: @@ -138,7 +138,7 @@ The geographical location of each node is based on the [`locality` property of t On the network screen, you can see your Node's location, and the location of peers on your network. -{{< figure alt="Map view" width=80% zoom="resources/node-explorer/node-explorer-map.png" >}} +{{< figure alt="Map view" width=80% src="resources/node-explorer/node-explorer-map.png" >}} ## Execute transaction flows @@ -153,7 +153,7 @@ You can use Node Explorer to execute a range of commonly used flows, however not You can execute each flow by completing the required information in the UI, without any additional coding. Node Explorer identifies the required fields in your CorDapps, and presents them for you to complete. -{{< figure alt="Flows" width=80% zoom="resources/node-explorer/node-explorer-flow.png" >}} +{{< figure alt="Flows" width=80% src="resources/node-explorer/node-explorer-flow.png" >}} To execute a transaction flow: @@ -185,13 +185,13 @@ You have accessed the details of a transaction. You can see general details as w You can see the transaction organised by the inputs and outputs of the transaction state that exists as a result of an executed flow. There can be multiple inputs and outputs for each transaction - for example, when a loan has been issued and then partly repaid. -{{< figure alt="Transaction explorer" width=80% zoom="resources/node-explorer/node-explorer-transactions.png" >}} +{{< figure alt="Transaction explorer" width=80% src="resources/node-explorer/node-explorer-transactions.png" >}} ## Explore your node's vault The vault keeps the full transaction history of your node. You can use the dynamically populated filters to explore transactions of all types, for example transactions with a Contract state type of `CashState`. -{{< figure alt="Vault explorer" width=80% zoom="resources/node-explorer/node-explorer-vault.png" >}} +{{< figure alt="Vault explorer" width=80% src="resources/node-explorer/node-explorer-vault.png" >}} To access your node's vault: diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/collaborative-recovery/deployment-and-operations.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/collaborative-recovery/deployment-and-operations.md index ac2e8190bbb..fdfbf6aa2e3 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/collaborative-recovery/deployment-and-operations.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/collaborative-recovery/deployment-and-operations.md @@ -90,7 +90,7 @@ The space complexities are outlined below: You can see a suggested high-level, disaster recovery setup in the diagram below. -{{< figure alt="Suggested Disaster Recovery Setup" width=80% zoom="../../resources/collaborative-recovery/dr-setup.png" >}} +{{< figure alt="Suggested Disaster Recovery Setup" width=80% src="../../resources/collaborative-recovery/dr-setup.png" >}} The exact setup you choose is likely to be influenced by your organisation and business requirements, but the key points are: diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/collaborative-recovery/introduction-cr.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/collaborative-recovery/introduction-cr.md index f2f33355c82..5c39af76318 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/collaborative-recovery/introduction-cr.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/collaborative-recovery/introduction-cr.md @@ -143,7 +143,7 @@ inbound / outbound reconciliations and also supports different throttling techni A high-level, peer-to-peer reconciliation flow is depicted in the diagram below. **LedgerSync** can run multiple reconciliations concurrently, up to the limit configured by the user. -{{< figure alt="Peer-to-Peer Reconciliation Flow" width=80% zoom="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} +{{< figure alt="Peer-to-Peer Reconciliation Flow" width=80% src="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} ### LedgerRecover @@ -166,7 +166,7 @@ supports different types of throttling to prevent accidental abuse of the functi A high-level, peer-to-peer automatic recovery flow is depicted in the diagram below. -{{< figure alt="Peer-to-Peer Automatic Recovery Flow" width=80% zoom="../../resources/collaborative-recovery/automatic-ledger-recover-flow.png" >}} +{{< figure alt="Peer-to-Peer Automatic Recovery Flow" width=80% src="../../resources/collaborative-recovery/automatic-ledger-recover-flow.png" >}} {{< attention >}} Even though the recovery flow contains the word "automatic" in its name, it can only be started manually. @@ -185,7 +185,7 @@ the import has been stopped halfway through. A high-level, peer-to-peer manual recovery flow is depicted in the diagram below. -{{< figure alt="Peer-to-Peer Manual Recovery Flow" width=80% zoom="../../resources/collaborative-recovery/manual-ledger-recover-flow.png" >}} +{{< figure alt="Peer-to-Peer Manual Recovery Flow" width=80% src="../../resources/collaborative-recovery/manual-ledger-recover-flow.png" >}} ### Supported disaster recovery scenarios diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/collaborative-recovery/ledger-sync.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/collaborative-recovery/ledger-sync.md index 1ce26c37d5c..e29b15edf6e 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/collaborative-recovery/ledger-sync.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/collaborative-recovery/ledger-sync.md @@ -28,7 +28,7 @@ All reconciliations are added to a bounded execution pool, which is configurable This means the node that requested the reconciliation will be notified if the responding node has transactions that the requesting node does not. The responding node will not be notified if the requesting node has transactions that the responding node does not. -{{< figure alt="Ledger Sync Flow" width=80% zoom="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} +{{< figure alt="Ledger Sync Flow" width=80% src="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} ## System requirements diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/component-topology.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/component-topology.md index 6c476fe13d5..07c61f24533 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/component-topology.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/component-topology.md @@ -16,7 +16,7 @@ weight: 30 It is useful to take a high level perspective of the Corda components, especially the various communication protocols that Corda employs in its operations. The diagram below illustrates the various communication protocols used by the Corda Node communicating with peers on the Corda Network. -{{< figure alt="overview" width=80% zoom="../resources/overview.png" >}} +{{< figure alt="overview" width=80% src="../resources/overview.png" >}} Corda Nodes communicate with each other using the asynchronous AMQP/TLS 1.2 protocols. HTTP communication is only used for initial registration of Corda Nodes and sharing the Corda Node address locations by way of the network map. Client applications communicate with Corda Nodes using RPC calls. A Node’s vault is a database that relies on JDBC connection from the Corda Node. When hosting a Corda Node on-premise, it’s important to consider: @@ -31,7 +31,7 @@ When hosting a Corda Node on-premise, it’s important to consider: In any given production deployment of Corda Enterprise, the most common components are the Corda Node, vault, and firewall. -{{< figure alt="nodebridgefloat nbrs" width=80% zoom="../resources/nodebridgefloat_nbrs.png" >}} +{{< figure alt="nodebridgefloat nbrs" width=80% src="../resources/nodebridgefloat_nbrs.png" >}} A typical Node deployment. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/corda-firewall-component.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/corda-firewall-component.md index 95c4d1b3947..f6e2d078f71 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/corda-firewall-component.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/corda-firewall-component.md @@ -139,7 +139,7 @@ Artemis with the node as TLS endpoint and to have the outgoing packets use the i Typically this should only be used for easy development, or for organisations evaluating on Open Source Corda, where this is the only available option: -{{< figure alt="node embedded bridge" width=80% zoom="/en/images/node_embedded_bridge.png" >}} +{{< figure alt="node embedded bridge" width=80% src="/en/images/node_embedded_bridge.png" >}} ### Node + Combined Bridge/Float (no DMZ) @@ -169,7 +169,7 @@ Then configure an all-in-one bridge to point at this node’s `messagingServerAd {{< /note >}} -{{< figure alt="simple bridge" width=80% zoom="/en/images/simple_bridge.png" >}} +{{< figure alt="simple bridge" width=80% src="/en/images/simple_bridge.png" >}} #### node.conf @@ -237,7 +237,7 @@ key, the tunnel link should use a private set of link specific keys and certific dynamically with the official TLS key when activated via the tunnel and this key will never be stored in the DMZ: {{< /note >}} -{{< figure alt="node bridge float" width=80% zoom="/en/images/node_bridge_float.png" >}} +{{< figure alt="node bridge float" width=80% src="/en/images/node_bridge_float.png" >}} #### node.conf @@ -325,7 +325,7 @@ Some organisations require dynamic outgoing connections to operate via a SOCKS p by adding extra information to the `outboundConfig` section of the bridge process. A simplified example deployment is shown here to highlight the option: -{{< figure alt="socks proxy" width=80% zoom="/en/images/socks_proxy.png" >}} +{{< figure alt="socks proxy" width=80% src="/en/images/socks_proxy.png" >}} #### node.conf @@ -425,7 +425,7 @@ Highlighted in the diagram is the addition of the `haConfig` section to point at addresses in the `alternateArtemisAddresses` to allow node failover and in the `floatAddresses` to point at a pool of DMZ float processes. -{{< figure alt="ha nodes" width=80% zoom="/en/images/ha_nodes.png" >}} +{{< figure alt="ha nodes" width=80% src="/en/images/ha_nodes.png" >}} #### node.conf @@ -562,7 +562,7 @@ It is possible to allow two or more Corda nodes (HA and/or non-HA) handle outgoi an external Artemis messaging broker which can be easily configured using the ha-tool. For more information, please see HA Utilities. While this example is the simplest deployment possible with a shared bridge, any other configuration previously presented can be created. -{{< figure alt="multiple nodes no ha" width=80% zoom="/en/images/multiple_nodes_no_ha.png" >}} +{{< figure alt="multiple nodes no ha" width=80% src="/en/images/multiple_nodes_no_ha.png" >}} #### bank-a-node.conf diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/corda-firewall-configuration-file.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/corda-firewall-configuration-file.md index 1536d5979c6..d87f16830c6 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/corda-firewall-configuration-file.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/corda-firewall-configuration-file.md @@ -131,14 +131,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -151,7 +151,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/deploy/env-prod-test.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/deploy/env-prod-test.md index b716198a72b..d13fcdd3c81 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/deploy/env-prod-test.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/deploy/env-prod-test.md @@ -33,12 +33,12 @@ There are alternative approaches to how these components are deployed. For the p When deploying Corda Enterprise in a testing environment the Node, Bridge, and Float components should be deployed in a non-HA configuration as shown in the following diagram. -{{< figure alt="nonha" width=80% zoom="../../resources/nonha.png" >}} +{{< figure alt="nonha" width=80% src="../../resources/nonha.png" >}} When deploying Corda Enterprise in a production environment, the Node, Bridge, and Float components should be deployed in a high-availability configuration. -{{< figure alt="ha" width=80% zoom="../../resources/ha.png" >}} +{{< figure alt="ha" width=80% src="../../resources/ha.png" >}} ### Deployment details @@ -206,7 +206,7 @@ This is a sample `node.conf` which details a configuration connecting to the Cor In a bank environment there will typically be several layers of security protecting the firms data. -{{< figure alt="cordarch" width=80% zoom="../../resources/cordarch.png" >}} +{{< figure alt="cordarch" width=80% src="../../resources/cordarch.png" >}} *Network Authentication* @@ -220,7 +220,7 @@ In a bank environment there will typically be several layers of security protect * Corda PKI Authentication issued by Corda Network can link the Node and Bridge i.e. the red keys indicated below truststore and sslkeystore * Local PKI Authentication issued by separate CA will link the Bridge and Float i.e the purple keys indicated below trust and Bridge. -{{< figure alt="firewallpki" width=80% zoom="../../resources/firewallpki.png" >}} +{{< figure alt="firewallpki" width=80% src="../../resources/firewallpki.png" >}} The key thing is to look at this from the perspective of a bank implementing these Corda and Local PKI keys. @@ -375,7 +375,7 @@ Administrative logins with the Corda Node happen via ssh whose port is configure The following image may be helpful in ensuring alignment between the Node, Bridge and Float configuration files. -{{< figure alt="CordaFirewallConfigAlign" width=80% zoom="../../resources/CordaFirewallConfigAlign.png" >}} +{{< figure alt="CordaFirewallConfigAlign" width=80% src="../../resources/CordaFirewallConfigAlign.png" >}} {{< note >}} **p2pAddress** reflects the **publicly accessible address**, which may or may not be the Float inboundConfig.listeningAddress. If there is an internet firewall configured in front of the Float then ask the Network Administrator for the public address that routes to the Float’s **listeningAddress**, and use that public address for your **p2pAddress**. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/deploy/hot-cold-deployment.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/deploy/hot-cold-deployment.md index 3df02f30eeb..f34916898df 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/deploy/hot-cold-deployment.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/deploy/hot-cold-deployment.md @@ -36,7 +36,7 @@ resources for both **Microsoft Azure** and **Amazon Web Services**. The image be result from following the guide. There will be two Corda Enterprise nodes, one active and the other inactive. Each node will represent the same legal identity inside the Corda network. Both will share a database and a network file system. -{{< figure alt="hot cold" width=80% zoom="../../resources/hot-cold.png" >}} +{{< figure alt="hot cold" width=80% src="../../resources/hot-cold.png" >}} ## Configuring the load balancer diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/node-administration.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/node-administration.md index 99cb97c971f..8a4661a2496 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/node-administration.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/node-administration.md @@ -242,7 +242,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ### Monitoring via Graphite diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/operating/monitoring-logging.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/operating/monitoring-logging.md index a259380302f..5594a014c38 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/operating/monitoring-logging.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/operating/monitoring-logging.md @@ -142,7 +142,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ### Monitoring via Graphite diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/operating/node-administration.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/operating/node-administration.md index 93f73c70af5..d65b3d3cc5a 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/operating/node-administration.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/operating/node-administration.md @@ -242,7 +242,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ### Monitoring via Graphite diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/operating/node-database-tables.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/operating/node-database-tables.md index 8b846d94f34..65c071684ee 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/operating/node-database-tables.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/operating/node-database-tables.md @@ -43,7 +43,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more in [Network map](../../network/network-map.md). -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -169,7 +169,7 @@ Read more in [Ledger](../../key-concepts-ledger.md). Read more in [Working with attachments](../../tutorial-attachments.md) and [Node services](../../node-services.md). -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -465,7 +465,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -494,7 +494,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/pki-guide.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/pki-guide.md index 5c49d580e9b..aea60a13b90 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/pki-guide.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/node/pki-guide.md @@ -54,7 +54,7 @@ as they root to the same certificate. Other than that, Corda nodes stay agnostic to the certificate hierarchy (in particular the depth of the certificate hierarchy tree). -{{< figure alt="hierarchy agnostic" width=80% zoom="../resources/hierarchy-agnostic.png" >}} +{{< figure alt="hierarchy agnostic" width=80% src="../resources/hierarchy-agnostic.png" >}} At the time of writing this document, the Corda Network assumes the certificate hierarchy that can be found [here](../../../../../../en/platform/corda/4.6/enterprise/network/permissioning.md). @@ -69,7 +69,7 @@ The network operator is responsible for certificate issuance and maintenance for at the Identity Manager and Network Map certificates. The rest of the certificate chain (i.e. every certificate below the Identity Manager certificate) falls into node operator responsibility. -{{< figure alt="tls hierarchy" width=80% zoom="../resources/tls-hierarchy.png" >}} +{{< figure alt="tls hierarchy" width=80% src="../resources/tls-hierarchy.png" >}} The certificate revocation list verification applies to the entire chain. This means that every certificate in the chain is going to be validated against the corresponding certificate revocation list during the SSL handshake. Consequently, this means that a node operator is expected to provide and maintain the certificate revocation list for the Node CA. @@ -87,7 +87,7 @@ During the certificate revocation list validation process the trust store is con As an example, let us consider the following certificate hierarchy: -{{< figure alt="example hierarchy" width=80% zoom="../resources/example-hierarchy.png" >}} +{{< figure alt="example hierarchy" width=80% src="../resources/example-hierarchy.png" >}} The certificate hierarchy presented above is currently (as of the time of writing this document) used in the Corda Network. It follows practices applicable for certificate authorities providing a balance between security and simplicity of usage. In this scenario, a network operator wants to create a CA hierarchy where the self-signed Root CA issues a certificate for the Subordinate CA which in turn issues diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary-healthcheck.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary-healthcheck.md index 7055ba058c5..2caef618123 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary-healthcheck.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary-healthcheck.md @@ -171,4 +171,4 @@ monitor notary health via a dashboard or hook up an alerter. As an example, this view on a failing notary check. Note the metrics for *success*, *fail*, *inflight*, and *maxinflightTime* for the notary service and the cluster members on the left hand side. -{{< figure alt="hawtio healthcheck" width=80% zoom="./resources/hawtio-healthcheck.png" >}} +{{< figure alt="hawtio healthcheck" width=80% src="./resources/hawtio-healthcheck.png" >}} diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary/backup-restore.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary/backup-restore.md index f588a26db24..4239d36045d 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary/backup-restore.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary/backup-restore.md @@ -29,7 +29,7 @@ Additionally, it is critical to have a backup of the Notary Service identity pri The following diagram highlights in blue which storage components should be backed up. -{{< figure alt="storage components" width=80% zoom="../resources/storage-components.png" >}} +{{< figure alt="storage components" width=80% src="../resources/storage-components.png" >}} Note that for regular nodes it is very important to back up the Messaging Broker (Artemis) folder and the local Database, but for HA notary nodes that are purely used for notarisation purposes that is not needed. To summarise: diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary/ha-notary-service-overview.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary/ha-notary-service-overview.md index 72f3bc8e760..ac81e83f4b0 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary/ha-notary-service-overview.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary/ha-notary-service-overview.md @@ -60,7 +60,7 @@ database to store its node state (e.g. its identity information). We can visualise this set-up as follows, with the regular Corda nodes in green, the Corda notary worker nodes in red, and the standard node databases and notary state database replicas in blue. -{{< figure alt="ha notary overview2" width=80% zoom="../resources/ha-notary-overview2.png" >}} +{{< figure alt="ha notary overview2" width=80% src="../resources/ha-notary-overview2.png" >}} Nodes requesting notarisation from a highly-available notary will connect to the notary workers in round-robin fashion. Provided there are multiple notary workers and the notary state database is configured to be highly-available, the overall notary service @@ -75,7 +75,7 @@ depending on your throughput and latency requirements. If desired, you can choose to run each database server and its Corda notary worker on the same machine: -{{< figure alt="ha notary colocated" width=80% zoom="../resources/ha-notary-colocated.png" >}} +{{< figure alt="ha notary colocated" width=80% src="../resources/ha-notary-colocated.png" >}} ## Notary configuration diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary/hsm-support.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary/hsm-support.md index 879031a6afa..3d74489bcef 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary/hsm-support.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/notary/hsm-support.md @@ -14,7 +14,7 @@ weight: 3 ## Overview -{{< figure alt="hsm support" width=80% zoom="../resources/hsm-support.png" >}} +{{< figure alt="hsm support" width=80% src="../resources/hsm-support.png" >}} Two notary workers and their relevant cryptographic keys used for P2P messaging and transaction signing. The red rectangles represent the Corda notary worker services. The distinct identity keys are represented by rectangles in green and yellow and the shared key of the notary service identity is drawn in blue. Their cryptographic keys are held in a single HSM. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/cenm-upgrade.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/cenm-upgrade.md index 88bb18a9028..f56764ca400 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/cenm-upgrade.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/cenm-upgrade.md @@ -352,13 +352,13 @@ Once this has been done the following steps should be followed to upgrade the se For example for the Doorman service: -{{< figure alt="doorman migration" width=80% zoom="/en/images/doorman-migration.png" >}} +{{< figure alt="doorman migration" width=80% src="/en/images/doorman-migration.png" >}} These steps should be followed for both the Doorman and Network Map Services. This process is *non-destructive* - it should leave the old database untouched, only copying the data across to the new databases. Once both services have been migrated via the above process they will be fully functional: -{{< figure alt="separated services" width=80% zoom="/en/images/separated-services.png" >}} +{{< figure alt="separated services" width=80% src="/en/images/separated-services.png" >}} ### Other required changes diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/env-prod-test.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/env-prod-test.md index 591dcca8e12..483219781b1 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/env-prod-test.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/env-prod-test.md @@ -34,12 +34,12 @@ There are alternative approaches to how these components are deployed. For the p When deploying Corda Enterprise in a testing environment the Node, Bridge, and Float components should be deployed in a non-HA configuration as shown in the following diagram. -{{< figure alt="nonha" width=80% zoom="../../resources/nonha.png" >}} +{{< figure alt="nonha" width=80% src="../../resources/nonha.png" >}} When deploying Corda Enterprise in a production environment, the Node, Bridge, and Float components should be deployed in a high-availability configuration. -{{< figure alt="ha" width=80% zoom="../../resources/ha.png" >}} +{{< figure alt="ha" width=80% src="../../resources/ha.png" >}} ### Deployment details @@ -207,7 +207,7 @@ This is a sample `node.conf` which details a configuration connecting to the Cor In a bank environment there will typically be several layers of security protecting the firms data. -{{< figure alt="cordarch" width=80% zoom="../../resources/cordarch.png" >}} +{{< figure alt="cordarch" width=80% src="../../resources/cordarch.png" >}} *Network Authentication* @@ -221,7 +221,7 @@ In a bank environment there will typically be several layers of security protect * Corda PKI Authentication issued by Corda Network can link the Node and Bridge i.e. the red keys indicated below truststore and sslkeystore * Local PKI Authentication issued by separate CA will link the Bridge and Float i.e the purple keys indicated below trust and Bridge. -{{< figure alt="firewallpki" width=80% zoom="../../resources/firewallpki.png" >}} +{{< figure alt="firewallpki" width=80% src="../../resources/firewallpki.png" >}} The key thing is to look at this from the perspective of a bank implementing these Corda and Local PKI keys. @@ -376,7 +376,7 @@ Administrative logins with the Corda Node happen via ssh whose port is configure The following image may be helpful in ensuring alignment between the Node, Bridge and Float configuration files. -{{< figure alt="CordaFirewallConfigAlign" width=80% zoom="../../resources/CordaFirewallConfigAlign.png" >}} +{{< figure alt="CordaFirewallConfigAlign" width=80% src="../../resources/CordaFirewallConfigAlign.png" >}} {{< note >}} **p2pAddress** reflects the **publicly accessible address**, which may or may not be the Float inboundConfig.listeningAddress. If there is an internet firewall configured in front of the Float then ask the Network Administrator for the public address that routes to the Float’s **listeningAddress**, and use that public address for your **p2pAddress**. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/firewall-deployment.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/firewall-deployment.md index 775f57a78a0..6549daafc67 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/firewall-deployment.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/firewall-deployment.md @@ -129,14 +129,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -149,7 +149,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/hot-cold-deployment.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/hot-cold-deployment.md index edd62e9e7cb..d9c9f59238a 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/hot-cold-deployment.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/operations/deployment/hot-cold-deployment.md @@ -37,7 +37,7 @@ resources for both **Microsoft Azure** and **Amazon Web Services**. The image be result from following the guide. There will be two Corda Enterprise nodes, one active and the other inactive. Each node will represent the same legal identity inside the Corda network. Both will share a database and a network file system. -{{< figure alt="hot cold" width=80% zoom="../../resources/hot-cold.png" >}} +{{< figure alt="hot cold" width=80% src="../../resources/hot-cold.png" >}} ## Configuring the load balancer diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/introduction.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/introduction.md index eca43d9e20b..55ae1cb7f68 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/introduction.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/introduction.md @@ -109,7 +109,7 @@ The driving app sits outside the network and connects to the JMeter servers thro measuring the throughput of a node, the test definition instructs all JMeter servers to open RPC connections to one node, thus saturating the RPC handler and driving the node as hard as possible. The test might invoke a flow that can be completed locally (for example, cash issuance) or it might require exchanging P2P messages with other nodes (for example, cash payment). -{{< figure alt="jmeter network overview" width=80% zoom="../resources/jmeter-network-overview.png" >}} +{{< figure alt="jmeter network overview" width=80% src="../resources/jmeter-network-overview.png" >}} ## Performance Tests diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/jmeter-samplers.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/jmeter-samplers.md index d981b451e05..6fa98081b14 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/jmeter-samplers.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/jmeter-samplers.md @@ -66,7 +66,7 @@ server, not the client machine. * `minimumNodePlatformVersion`: the minimum platform version that the JMeter client will require from the Corda nodes. It defaults to 4, which can be used to test with Corda 4.0 nodes or later. * `username`: the RPC user name of the Corda node. * `password`: the RPC password of the Corda node. -{{< figure alt="empty flow sampler" width=80% zoom="../resources/empty-flow-sampler.png" >}} +{{< figure alt="empty flow sampler" width=80% src="../resources/empty-flow-sampler.png" >}} * `CashIssueSampler`: this sampler client has the class name `com.r3.corda.jmeter.CashIssueSampler` and starts the flow `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueFlow`. This flow self-issues 1.1 billion cash tokens on the node it is running on, and stores it in the vault. In addition to the common properties described for `EmptyFlowSampler` above, this sampler client also requires: * `notaryName`: the X500 name of the notary that is acceptable to transfer cash tokens issued via this sampler. Issuing tokens does not need to be notarised, and therefore invoking this sampler does not create traffic to the notary. However, the notary is stored as part of the cash state and must be valid to do anything else with the cash state, therefore this sampler checks the notary identity against the network parameters of the node. * `CashIssueAndPaySampler`: this sampler client has the classname `com.r3.corda.jmeter.CashIssueAndPaySampler` and, depending on its parameters, it can start either of these flows - `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndPaymentFlow` or `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndpaymentNoSelection`. Either way it issues 2 million dollars in tokens and then transfers the sum to a configurable other node, thus invoking the full vault access, peer-to-peer communication and notarisation cycle. In addition to the parameters required for `CashIssueSampler`, this sampler also requires: diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/jmeter-testplans.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/jmeter-testplans.md index 5cbe86a5dfb..7a6ac6a6a89 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/jmeter-testplans.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/jmeter-testplans.md @@ -25,12 +25,12 @@ The testplan is a hierarchy of configuration elements. The only elements used in *Variables*, *Thread Groups*, *Samplers* and *Listeners*. Rather than creating a new testplan from scratch, it might a good idea to take a copy of one of the provided example test plans and modify that. -{{< figure alt="jmeter testplan" width=80% zoom="../resources/jmeter-testplan.png" >}} +{{< figure alt="jmeter testplan" width=80% src="../resources/jmeter-testplan.png" >}} A variables element defines key/value pairs that can be used in all following following elements instead of string literals. They can be referenced by using a `$` sign and curly braces, e.g. `${varName}`. -{{< figure alt="variables" width=80% zoom="../resources/variables.png" >}} +{{< figure alt="variables" width=80% src="../resources/variables.png" >}} A thread group collects a set of actions that form one step in the test plan. All elements within a thread group diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/performance-results.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/performance-results.md index 3d9b7f1de3e..fe3a067ff8c 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/performance-results.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/performance-results.md @@ -40,7 +40,7 @@ the time of Corda Enterprise Edition 4 release). This is with each node running running **Microsoft SQL Server**. Similar results were obtained against the other supported databases. -{{< figure alt="ce4 comparison chart" width=80% zoom="/en/images/ce4-comparison-chart.png" >}} +{{< figure alt="ce4 comparison chart" width=80% src="/en/images/ce4-comparison-chart.png" >}} Figure 1 @@ -52,7 +52,7 @@ varies with the number of those payments combined together. This can be useful be a technique for even greater throughput. -{{< figure alt="states per second" width=80% zoom="/en/images/states-per-second.png" >}} +{{< figure alt="states per second" width=80% src="/en/images/states-per-second.png" >}} Figure 2 @@ -65,7 +65,7 @@ of Figure 3 were achieved using Corda Enterprise 3.0 on **Microsoft Azure** virt with minimal latency between the node VM and the database server VM. -{{< figure alt="comparison chart" width=80% zoom="/en/images/comparison-chart.png" >}} +{{< figure alt="comparison chart" width=80% src="/en/images/comparison-chart.png" >}} Figure 3 @@ -303,7 +303,7 @@ All these machines were 24 core (48 hyper-threads), based on 2x Intel Xeon E5-26 The first test performed was focused on the latency aspect. Load was generated from a single client initialised in a machine that was separate from the ones hosting the Corda nodes and their databases. The load consisted of a pre-defined number of flows (400) that were executed one after the other sequentially. Each one of those flows was initiated on the central exchange node, which was responsible for collecting signatures from all the parties involved and for finalising the transaction. Each of those flows performed a swap of two states between every pair of nodes, thus leading to a Corda transaction with 10 input and 10 output states. During the test setup, the necessary amount of states was initially issued and each one of those states would be swapped once during the test. In order to also measure the impact of transaction resolution, during the test setup each of these states was transferred bilaterally between the nodes in each pair ten times, thus generating a backchain of depth 10. This meant that during every Corda transaction, each node would have to resolve the backchain of the states belonging to the other pairs - so each node would have to resolve 80 states (8 nodes x 10 states each). In order to also measure the scaling with regard to the number of nodes, the exact same test was repeated with a varying number of participants, starting from 4 nodes and going up to 10. The test was also repeated three times with Corda Enterprise versions 4.3, 4.4, and 4.5. The goal was to isolate the benefits from bulk transaction resolution, introduced in version 4.4, and parallelised flows (`CollectSignaturesFlow` / `FinalityFlow`), introduced in version 4.5. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average latency of the flow that performed the asset swap in milliseconds. -{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.3 shows an exponential increase in the latency of the flow as the number of nodes that participate in the transaction is increased. This can be attributed to the following two reasons. Firstly, during the tests the exchange node was performing the `CollectSignaturesFlow` and `FinalityFlow` flows sequentially across the involved nodes, so the more nodes these flows had to iterate over, the more time it took. Secondly, these flows have the capability to trigger the execution of transaction resolution if they identify states for which the node is missing the provenance chain. In Corda Enterprise Edition 4.3, transaction resolution is not performed in bulk - it is performed one state at a time. As a result, every additional node causes a significant amount of extra work to be done. @@ -314,7 +314,7 @@ The main observations from the tests follow below: The second test was focused on the throughput aspect. Load was generated from multiple clients initialised on the machines that were hosting the Corda nodes, which were acting as JMeter servers orchestrated by a JMeter client running on a separate machine. The goal was to saturate the participating Corda nodes and to prevent the single client from becoming the bottleneck. During the test setup, each client issued one state to every node. Each client was then performing one flow at a time, swapping these states between the participating nodes. No backchain was generated as part of this test. As a result, the test was executed only between Corda Enterprise Edition 4.3 and Corda Enterprise Edition 4.5, and with a varying number of nodes ranging from 2 up to 10. Each of the machines driving the load was using 120 concurrent clients, which summed up to 480 concurrent clients in total. Additional measurements were performed with a varying number of clients, in order to ensure that this was the optimal number of clients to saturate the nodes without overloading them. Since the throughput was different depending on the number of participating nodes, the total number of requests was also adjusted accordingly in order to get roughly the same total duration of approximately 20 minutes. In all the scenarios, it was confirmed that the nodes had reached a stable state when the test ended. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average throughput measured in the number of flows completed per second. -{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.5 can achieve a significantly higher throughput when compared to Corda Enterprise Edition 4.3. This can be attributed to the following factors: @@ -336,9 +336,9 @@ Five different variations were tested, as follows: The purpose of this last test was to investigate the effects of these options in both throughput and latency because some of these options introduce trade-offs between these two aspects. To this end, the tests described earlier in this analysis were repeated using the variations listed above. For the latency measurements, 10 nodes were used because, thanks to the low load, there was no expectation for any big interference between nodes on the same machine. For the throughput measurements, only 4 nodes were used in order to avoid any interference between nodes on the same machine due to the high load. The results are shown in the diagrams below - the *x* axis contains the variations used, and the *y* axis shows the average throughput and latency achieved with each variation along with error bars indicating the standard deviation. -{{< figure alt="CE 4.5 variants latency comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_latency.png" >}} +{{< figure alt="CE 4.5 variants latency comparison chart" width=80% src="../resources/performance-testing/4-5_variants_latency.png" >}} -{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_throughput.png" >}} +{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% src="../resources/performance-testing/4-5_variants_throughput.png" >}} The main observations from the test are as follows: * Disabling compression leads to lower throughput and higher latency. This is expected because compression introduces a trade-off between CPU and network bandwidth utilisation and in most cases the network would prove to be a bigger bottleneck. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/practical-considerations.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/practical-considerations.md index 8243211ad9d..e9c56e52b65 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/practical-considerations.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/practical-considerations.md @@ -94,7 +94,7 @@ To collect the output of a JMeter performance run, we need to add listeners to t This listener just lists all the runs that have been completed, one run per row, stating the thread name, sampler label, the sample time in milliseconds, the result status and the latency in milliseconds, among other (usually less useful) fields. -{{< figure alt="jmeter results table" width=80% zoom="../resources/jmeter-results-table.png" >}} +{{< figure alt="jmeter results table" width=80% src="../resources/jmeter-results-table.png" >}} This view is particularly useful when trying out any changes (new flow, new sampler, new installation) to see if it is working at all. The potential outcomes are: @@ -123,7 +123,7 @@ This listener aggregates all the runs for each thread group and the whole test p It also allows plotting these statistics in basic charts and to save the results as a csv file. This is what we use for looking at the performance results on a day to day basis. -{{< figure alt="jmeter results aggregate" width=80% zoom="../resources/jmeter-results-aggregate.png" >}} +{{< figure alt="jmeter results aggregate" width=80% src="../resources/jmeter-results-aggregate.png" >}} This listener has one line for each sampler being run as part of the test plan, and a total line summing up/averaging the results for the whole test plan. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/r3-performance-runs.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/r3-performance-runs.md index 62fa35ad1ed..8c22609db0a 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/r3-performance-runs.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/r3-performance-runs.md @@ -32,7 +32,7 @@ The performance network sits behind a firewall that allows incoming connections within the network can connect to each other on a range of ports (Corda Remote Procedure Call (RPC), Corda peer to peer connection (P2P) and JDBC connections to various database servers are all allowed). -{{< figure alt="performance cluster" width=80% zoom="../resources/performance-cluster.png" >}} +{{< figure alt="performance cluster" width=80% src="../resources/performance-cluster.png" >}} A Corda JMeter server instance is running on all 4 nodes and on the notary server. The JMeter client connects to the JMeter server instances via SSH tunnels. As the JMeter servers run within the firewalled network, they are free to diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/running-jmeter-corda.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/running-jmeter-corda.md index ead19e73e84..fab50f5beac 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/running-jmeter-corda.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/performance-testing/running-jmeter-corda.md @@ -54,7 +54,7 @@ interactively either locally or remotely, and view results. The UI has a set of quickly create or load a testplan, control local or remote test runs, and clear any test results collected so far. The latter is particularly important when looking at averages, as old data might skew the results being looked at. -{{< figure alt="jmeter buttons" width=80% zoom="../resources/jmeter-buttons.png" >}} +{{< figure alt="jmeter buttons" width=80% src="../resources/jmeter-buttons.png" >}} The *clear current view* button only clears the data in the currently viewed output collector - if a test plan has several output listeners defined (as in the example above, we have *Aggregate Graph*, *Graph Results* and *View Results in Table*), any collector not currently selected is not affected. *Clear all data* will clear the results from all collectors. diff --git a/content/en/archived-docs/corda-enterprise/4.6/enterprise/upgrading-cordapp.md b/content/en/archived-docs/corda-enterprise/4.6/enterprise/upgrading-cordapp.md index b25de101cc1..7e9fc3fb585 100644 --- a/content/en/archived-docs/corda-enterprise/4.6/enterprise/upgrading-cordapp.md +++ b/content/en/archived-docs/corda-enterprise/4.6/enterprise/upgrading-cordapp.md @@ -37,7 +37,7 @@ The `version` property, which defaults to 1, specifies the flow’s version. Thi The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="./resources/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="./resources/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/archived-docs/corda-enterprise/4.7/api-core-types.md b/content/en/archived-docs/corda-enterprise/4.7/api-core-types.md index cadad76ab12..a3ff76fd153 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/api-core-types.md +++ b/content/en/archived-docs/corda-enterprise/4.7/api-core-types.md @@ -41,11 +41,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="./resources/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="./resources/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="./resources/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="./resources/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/archived-docs/corda-enterprise/4.7/apps/bankinabox/user-interface/how-to.md b/content/en/archived-docs/corda-enterprise/4.7/apps/bankinabox/user-interface/how-to.md index 0ee0e8eb28f..a5c0b96b26d 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/apps/bankinabox/user-interface/how-to.md +++ b/content/en/archived-docs/corda-enterprise/4.7/apps/bankinabox/user-interface/how-to.md @@ -70,7 +70,7 @@ Follow these steps to create a new customer profile. When the customer profile is created, they will not have any accounts - you will have to create them. Learn how under [Creating accounts](#create-a-current-account). {{< /note >}} -{{< figure alt="Create customer profile" width=80% zoom="/en/gifs/create-customer-biab-1.0.gif" >}} +{{< figure alt="Create customer profile" width=80% src="/en/gifs/create-customer-biab-1.0.gif" >}} ### Create a Current account @@ -94,7 +94,7 @@ When the customer profile is created, they will not have any accounts - you will 7. When an account is created, it is in **PENDING** status. This must be changed to **ACTIVE** for a customer to be able to interact with and use the account. See [Change an account status](#change-an-account-status) for more information. -{{< figure alt="Create account" width=80% zoom="/en/gifs/create-current-account-biab-1.0.gif" >}} +{{< figure alt="Create account" width=80% src="/en/gifs/create-current-account-biab-1.0.gif" >}} ### Create a Savings account @@ -140,7 +140,7 @@ An account has three statuses: **PENDING**, **ACTIVE**, and **SUSPENDED**. When If the account needs to be suspended, follow the same steps but select **SUSPENDED**. -{{< figure alt="Set account status" width=80% zoom="/en/gifs/set-account-status-biab-1.0.gif" >}} +{{< figure alt="Set account status" width=80% src="/en/gifs/set-account-status-biab-1.0.gif" >}} ### Assign or revoke a user role @@ -163,7 +163,7 @@ To assign a user role, follow these steps: 5. Click **Revoke**. A message will appear indicating that the user role was assigned successfully. -{{< figure alt="Assign role" width=80% zoom="/en/gifs/assign-a-role-biab-1.0.gif" >}} +{{< figure alt="Assign role" width=80% src="/en/gifs/assign-a-role-biab-1.0.gif" >}} #### Revoke a user role @@ -179,7 +179,7 @@ To revoke a user role, follow these steps: 5. Click **Save**. A message will appear indicating that the user role was revoked successfully. -{{< figure alt="Revoke role" width=80% zoom="/en/gifs/revoke-role-biab-1.0.gif" >}} +{{< figure alt="Revoke role" width=80% src="/en/gifs/revoke-role-biab-1.0.gif" >}} ### Issue a loan @@ -195,7 +195,7 @@ Once the account has been set to **ACTIVE**, you will have the ability to issue A loan account is created when a loan has been issued successfully. -{{< figure alt="Issue loan" width=80% zoom="/en/gifs/issue-loan-biab-1.0.gif" >}} +{{< figure alt="Issue loan" width=80% src="/en/gifs/issue-loan-biab-1.0.gif" >}} ### Approve overdrafts @@ -215,7 +215,7 @@ To approve an overdraft, follow these steps. Overdrafts can be approved whether the account is **PENDING**, **ACTIVE**, or **SUSPENDED**. {{< /note >}} -{{< figure alt="Approve overdraft" width=80% zoom="/en/gifs/approve-overdraft-biab-1.0.gif" >}} +{{< figure alt="Approve overdraft" width=80% src="/en/gifs/approve-overdraft-biab-1.0.gif" >}} ### Deposit money to an account @@ -230,7 +230,7 @@ Follow these steps to deposit money to a customer account. 4. Click **Save**. You will receive a message indicating that the deposit was successful. -{{< figure alt="Deposit" width=80% zoom="/en/gifs/deposit-biab-1.0.gif" >}} +{{< figure alt="Deposit" width=80% src="/en/gifs/deposit-biab-1.0.gif" >}} ### Register as a user on Bank in a Box @@ -251,7 +251,7 @@ You must be registered as a **Customer** or **Admin** on Bank in a Box to perfor 5. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update customer profile @@ -284,7 +284,7 @@ An **Admin user** can set an account's **Withdrawal daily limit** or **Transfer 2. Click **Save** when you've entered the desired limits. A message will appear indicating that the limits have been saved successfully. -{{< figure alt="Set withdrawal and transfer limits - admin" width=80% zoom="/en/gifs/set-limits-admin-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - admin" width=80% src="/en/gifs/set-limits-admin-biab-1.0.gif" >}} ## Customer tasks @@ -309,12 +309,12 @@ Follow these steps to create a new intrabank payment. 6. Click **Save**. You will receive a notification indicating that the payment was created successfully. You will also receive notifications indicating any changes in your account balances. -{{< figure alt="Create intrabank payment" width=80% zoom="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} +{{< figure alt="Create intrabank payment" width=80% src="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} After making a payment, you can view the details of this transaction on the Transactions screen. -{{< figure alt="View transaction" width="800" width=80% zoom="/en/gifs/view-transaction-biab-1.0.gif" >}} +{{< figure alt="View transaction" width="800" width=80% src="/en/gifs/view-transaction-biab-1.0.gif" >}} ### Create a recurring payment @@ -338,7 +338,7 @@ Follow these steps to create a recurring payment: 3. You will be taken back to the **Recurring payments screen** where you will receive a message indicating that the recurring payment was created successfully. -{{< figure alt="Recurring payment" width=80% zoom="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} +{{< figure alt="Recurring payment" width=80% src="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} {{< note >}} This payment will not appear on the **Recurring payments screen** until the first iteration has occurred. @@ -367,7 +367,7 @@ You must be registered as a Customer or Admin on Bank in a Box to perform tasks. 7. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update a customer profile @@ -406,4 +406,4 @@ To set these limits as a **Customer**, follow these steps. 4. Click **Save**. You will be taken back to the Account page where you will receive a message indicating that the limits have been updated successfully. -{{< figure alt="Set withdrawal and transfer limits - customer" width=80% zoom="/en/gifs/set-limits-customer-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - customer" width=80% src="/en/gifs/set-limits-customer-biab-1.0.gif" >}} diff --git a/content/en/archived-docs/corda-enterprise/4.7/contract-irs.md b/content/en/archived-docs/corda-enterprise/4.7/contract-irs.md index c19b8ca678d..707a57b7cb8 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/contract-irs.md +++ b/content/en/archived-docs/corda-enterprise/4.7/contract-irs.md @@ -45,7 +45,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="./resources/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="./resources/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/archived-docs/corda-enterprise/4.7/cordapp-advanced-concepts.md b/content/en/archived-docs/corda-enterprise/4.7/cordapp-advanced-concepts.md index 11efeeac4cc..96cf1250546 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/cordapp-advanced-concepts.md +++ b/content/en/archived-docs/corda-enterprise/4.7/cordapp-advanced-concepts.md @@ -71,7 +71,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="./resources/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="./resources/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/archived-docs/corda-enterprise/4.7/cordapps/api-flows.md b/content/en/archived-docs/corda-enterprise/4.7/cordapps/api-flows.md index c6287207f67..4c08bae6fc0 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/cordapps/api-flows.md +++ b/content/en/archived-docs/corda-enterprise/4.7/cordapps/api-flows.md @@ -62,7 +62,7 @@ In our flow, the Initiator flow class will be doing the majority of the work, th We can visualize the work performed by initiator as follows: -{{< figure alt="flow overview" width=80% zoom="../resources/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="../resources/flow-overview.png" >}} ## Responder diff --git a/content/en/archived-docs/corda-enterprise/4.7/cordapps/api-states.md b/content/en/archived-docs/corda-enterprise/4.7/cordapps/api-states.md index 7ec052cc567..8656e085c2f 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/cordapps/api-states.md +++ b/content/en/archived-docs/corda-enterprise/4.7/cordapps/api-states.md @@ -65,7 +65,7 @@ the total amount held that is important, rather than the actual units held. We can picture the hierarchy as follows: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/archived-docs/corda-enterprise/4.7/cordapps/cordapp-overview.md b/content/en/archived-docs/corda-enterprise/4.7/cordapps/cordapp-overview.md index 262b0dc1a8d..ae926a0f7e8 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/cordapps/cordapp-overview.md +++ b/content/en/archived-docs/corda-enterprise/4.7/cordapps/cordapp-overview.md @@ -18,7 +18,7 @@ CorDapps (Corda Distributed Applications) are distributed applications that run CorDapp is to allow nodes to reach agreement on updates to the ledger. They achieve this goal by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="../resources/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="../resources/node-diagram.png" >}} ## CorDapp components diff --git a/content/en/archived-docs/corda-enterprise/4.7/cordapps/deterministic-jvm.md b/content/en/archived-docs/corda-enterprise/4.7/cordapps/deterministic-jvm.md index 15951eef4a9..537cbbd6619 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/cordapps/deterministic-jvm.md +++ b/content/en/archived-docs/corda-enterprise/4.7/cordapps/deterministic-jvm.md @@ -75,7 +75,7 @@ severity `ERROR` will prevent execution. The sandbox has a configuration that applies to the execution of a specific runnable. This configuration, on a higher level, contains a set of rules, definition providers and emitters. -{{< figure alt="djvm overview" width=80% zoom="../resources/djvm-overview.png" >}} +{{< figure alt="djvm overview" width=80% src="../resources/djvm-overview.png" >}} The set of rules is what defines the constraints posed on the runtime environment. A rule can act on three different levels, namely on a type-, member- or instruction-level. The set of rules get processed and validated by the `RuleValidator` prior to execution. diff --git a/content/en/archived-docs/corda-enterprise/4.7/cordapps/upgrading-cordapps.md b/content/en/archived-docs/corda-enterprise/4.7/cordapps/upgrading-cordapps.md index 4b70be1ce59..3a12c76d014 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/cordapps/upgrading-cordapps.md +++ b/content/en/archived-docs/corda-enterprise/4.7/cordapps/upgrading-cordapps.md @@ -70,7 +70,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="../resources/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="../resources/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/archived-docs/corda-enterprise/4.7/financial-model.md b/content/en/archived-docs/corda-enterprise/4.7/financial-model.md index 384539b7ec6..12bb3362289 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/financial-model.md +++ b/content/en/archived-docs/corda-enterprise/4.7/financial-model.md @@ -90,6 +90,6 @@ countable (in cents), barrels of West Texas crude are fungible and countable (oi container), shares of the same class in a specific company are fungible and countable, and so on. The following diagram illustrates the complete Contract State hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Note there are currently two packages, a core library and a finance model specific library. Developers may re-use or extend the Finance types directly or write their own by extending the base types from the Core library. diff --git a/content/en/archived-docs/corda-enterprise/4.7/health-survey.md b/content/en/archived-docs/corda-enterprise/4.7/health-survey.md index a38186e0d26..3bdcd86cf39 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/health-survey.md +++ b/content/en/archived-docs/corda-enterprise/4.7/health-survey.md @@ -116,7 +116,7 @@ The Corda Health Survey currently does not support testing RPC communication if The tool generates the archive of the collected files in the same directory it is ran in. The names are in the format: `report-date-time.zip` -{{< figure alt="health survey photo" width=80% zoom="resources/health-survey-photo.png" >}} +{{< figure alt="health survey photo" width=80% src="resources/health-survey-photo.png" >}} ## Deployment health check diff --git a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-consensus.md b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-consensus.md index 738bffbb94a..d9a24530f32 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-consensus.md +++ b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-consensus.md @@ -53,7 +53,7 @@ transferring us a treasury bond. We can only be sure that the bond transfer is v The only way to be sure of both conditions is to walk the transaction’s chain. We can visualize this process as follows: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a given party may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer(s). The transaction proposer(s) will always have the full transaction chain, since they would have requested it when @@ -70,7 +70,7 @@ proposals: This is a problem because, although both transactions will achieve validity consensus, Bob has managed to “double-spend” his USD to get double the amount of GBP and EUR. We can visualize this as follows: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-contracts.md b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-contracts.md index b72d83d87ed..9a21b7a0fa6 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-contracts.md +++ b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-contracts.md @@ -47,7 +47,7 @@ valid We can picture this situation as follows: -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code has access to the full capabilities of the language, including: diff --git a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-ecosystem.md b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-ecosystem.md index 041954fb524..9214e431457 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-ecosystem.md +++ b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-ecosystem.md @@ -29,7 +29,7 @@ title: Network A Corda network is a peer-to-peer network of **nodes**. Each node represents a legal entity, and each runs the Corda software (an instance of Corda and one or more Corda applications, known as **CorDapps**). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} All communication between nodes is point-to-point and encrypted using transport-layer security. This means that data is shared only on a need-to-know basis. There are **no global broadcasts**. diff --git a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-flows.md b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-flows.md index bbfe0a33417..d7003a1fa56 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-flows.md +++ b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-flows.md @@ -36,7 +36,7 @@ what order. Here is a visualisation of the process of agreeing a simple ledger update between Alice and Bob: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -45,7 +45,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is the sequence of flow steps involved in the simple ledger update above: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-ledger.md b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-ledger.md index e62b939d055..bb34b11684c 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-ledger.md +++ b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-ledger.md @@ -37,7 +37,7 @@ The facts that a node knows about are those that it is involved with. For exampl Example: A network with five nodes, where each numbered circle on an intersection represents a fact shared between two or more nodes. -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} The preceding Venn diagram represents 5 nodes (Alice, Bob, Carl, Demi and Ed) as sets. Where the sets overlap are shared facts, such as those known by both Alice and Bob (1 and 7). Notably, in this Venn diagram, Alice only shares facts with Bob. Alice does not share facts with any of Carl, Demi or Ed. @@ -61,7 +61,7 @@ In the previous diagram, we could see that although Carl, Demi and Ed are aware You can think of this vault as being a database or simple table. -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} Where the rows are shared between nodes (facts 1 and 7 in this example), these are shared facts. Corda guarantees that whenever one of these facts is shared by multiple nodes on the network, it evolves in lockstep in the database of every node that is aware of it. This means that Alice and Bob will both see an **exactly identical version** of shared facts 1 and 7. diff --git a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-node.md b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-node.md index aaefc8c8d8a..54f2374264b 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-node.md +++ b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-node.md @@ -37,7 +37,7 @@ CorDapps. We can visualize the node’s internal architecture as follows: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: * A persistence layer for storing data diff --git a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-states.md b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-states.md index 7c446eb5e26..41fdf155d68 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-states.md +++ b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-states.md @@ -36,7 +36,7 @@ identity information…). For example, the following state represents an IOU - an agreement that Alice owes Bob an amount X: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} Specifically, this state represents an IOU of £10 from Alice to Bob. As well as any information about the fact itself, the state also contains a reference to the *contract* that governs @@ -53,14 +53,14 @@ historic. This sequence of state replacements gives us a full view of the evolution of the shared fact over time. We can picture this situation as follows: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a *vault* - a database where it tracks all the current and historic states that it is aware of, and which it considers to be relevant to itself: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} We can think of the ledger from each node’s point of view as the set of all the current (i.e. non-historic) states that it is aware of. diff --git a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-tearoffs.md b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-tearoffs.md index 22e70848361..2a0e1ac2154 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-tearoffs.md +++ b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-tearoffs.md @@ -58,7 +58,7 @@ reveal the content of low-entropy hashed values (i.e., a single-word text attach After computing the leaves, each Merkle tree is built in the normal way by hashing the concatenation of nodes’ hashes below the current one together. It’s visible on the example image below, where `H` denotes sha256 function, “+” - concatenation. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} The transaction has three input states, two output states, two commands, one attachment, a notary and a time-window. Notice that if a tree is not a full binary tree, leaves are padded to the nearest power of 2 with zero hash (since finding a pre-image of sha256(x) == 0 is hard computational task) - marked light @@ -77,7 +77,7 @@ Let’s assume that only the first command should be visible to an Oracle. We sh the commands requiring a signature from this oracle should be visible to the oracle entity, but not the rest. Here is how this filtered transaction will be represented in the Merkle tree structure. -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} Blue nodes and `H(c2)` are provided to the Oracle service, while the black ones are omitted. `H(c2)` is required, so that the Oracle can compute `H(commandData)` without being to able to see the second command, but at the same time ensuring `CommandData1` is part of the transaction. It is highlighted that all signers are visible, so as to have a @@ -93,4 +93,4 @@ apart from input states, time-window and the notary information. This data is en input states should be checked for double-spending, if the time-window is valid and if this transaction should be notarised by this notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-time-windows.md b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-time-windows.md index 9bdca76532e..9c5687adf89 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-time-windows.md +++ b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-time-windows.md @@ -53,7 +53,7 @@ For this reason, times in transactions are specified as time *windows*, not abso there can never be “true time”, only an approximation of it. Time windows can be open-ended (i.e. specify only one of “before” and “after”) or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} In this way, we express the idea that the *true value* of the fact “the current time” is actually unknowable. Even when both a before and an after time are included, the transaction could have occurred at any point within that time-window. diff --git a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-transactions.md b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-transactions.md index e15d5e7025d..80643078121 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-transactions.md +++ b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-transactions.md @@ -39,7 +39,7 @@ single link in the state sequences seen in [States](key-concepts-states.md). Here is an example of an update transaction, with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type: * They can include many different state types (states may represent cash or bonds, for example) @@ -66,7 +66,7 @@ These input states references are a combination of: This situation can be illustrated as follows: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} These input state references link transactions together over time, forming what is known as a *transaction chain*. {{< note >}} @@ -78,14 +78,14 @@ See [Reissuing states](reissuing-states.md) for information about reissuing stat Initially, a transaction is just a **proposal** to update the ledger. It represents the future state of the ledger that is desired by the transaction builders: -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To become reality, the transaction must receive signatures from all of the *required signers* (see **Commands**, below). Each required signer appends their signature to the transaction to indicate that they approve the proposal: -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If all of the required signatures are gathered, the transaction becomes committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions @@ -132,7 +132,7 @@ This transaction comprises two commands: a settlement command which reduces the has two supporting attachments, and will only be notarised by NotaryClusterA if the notary pool receives it within the specified time-window. This transaction would look as follows: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -160,7 +160,7 @@ listed in the commands, we get the list of the transaction’s required signers. We can visualize this situation as follows: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-vault.md b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-vault.md index 08ca0eca381..42a4b3dd788 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/key-concepts-vault.md +++ b/content/en/archived-docs/corda-enterprise/4.7/key-concepts-vault.md @@ -65,7 +65,7 @@ The vault supports the management of data in both authoritative (“on-ledger” The following diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} Note the following: diff --git a/content/en/archived-docs/corda-enterprise/4.7/network/azure-vm.md b/content/en/archived-docs/corda-enterprise/4.7/network/azure-vm.md index 1d7fb892e1f..86d86f452e1 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/network/azure-vm.md +++ b/content/en/archived-docs/corda-enterprise/4.7/network/azure-vm.md @@ -44,7 +44,7 @@ Define the basic parameters which will be used to pre-configure your Corda nodes * **Resource group**: Choose to ‘Create new’ and provide a useful name of your choice * **Location**: Select the geographical location physically closest to you -{{< figure alt="azure multi node step1" width=80% zoom="../resources/azure_multi_node_step1.png" >}} +{{< figure alt="azure multi node step1" width=80% src="../resources/azure_multi_node_step1.png" >}} Click ‘OK’ STEP 2: Network Size and Performance @@ -58,7 +58,7 @@ Define the number of Corda nodes in your network and the size of VM. * **Storage performance**: Leave as ‘Standard’ * **Virtual machine size**: The size of the VM is automatically adjusted to suit the number of participant nodes selected. R3 recommends to use the suggested values -{{< figure alt="azure multi node step2" width=80% zoom="../resources/azure_multi_node_step2.png" >}} +{{< figure alt="azure multi node step2" width=80% src="../resources/azure_multi_node_step2.png" >}} Click ‘OK’ STEP 3: Corda Specific Options @@ -69,14 +69,14 @@ Define the version of Corda you want on your nodes and the type of notary. * **Corda version (as seen in Maven Central)**: Select the version of Corda you want your nodes to use from the drop down list. The version numbers can be seen in [Maven Central](http://repo1.maven.org/maven2/net/corda/corda/), for example 0.11.0 * **Notary type**: Select either ‘Non Validating’ (notary only checks whether a state has been previously used and marked as historic) or ‘Validating’ (notary performs transaction verification by seeing input and output states, attachments and other transaction information). More information on notaries can be found [here](https://vimeo.com/album/4555732/video/214138458) -{{< figure alt="azure multi node step3" width=80% zoom="../resources/azure_multi_node_step3.png" >}} +{{< figure alt="azure multi node step3" width=80% src="../resources/azure_multi_node_step3.png" >}} Click ‘OK’ STEP 4: Summary A summary of your selections is shown. -{{< figure alt="azure multi node step4" width=80% zoom="../resources/azure_multi_node_step4.png" >}} +{{< figure alt="azure multi node step4" width=80% src="../resources/azure_multi_node_step4.png" >}} Click ‘OK’ for your selection to be validated. If everything is ok you will see the message ‘Validation passed’ Click ‘OK’ @@ -91,7 +91,7 @@ Once deployed click ‘Resources Groups’, select the resource group you define The Network Map Service node is suffixed nm0. The Notary node is suffixed not0. Your Corda participant nodes are suffixed node0, node1, node2 etc. Note down the **Public IP address** for your Corda nodes. You will need these to connect to UI screens via your web browser: -{{< figure alt="azure ip" width=80% zoom="../resources/azure_ip.png" >}} +{{< figure alt="azure ip" width=80% src="../resources/azure_ip.png" >}} ## Using the Yo! CorDapp @@ -132,7 +132,7 @@ where (public IP address) is the public IP address of one of your Corda nodes on You will now see the Yo! CorDapp web interface: -{{< figure alt="Yo web ui" width=80% zoom="../resources/Yo_web_ui.png" >}} +{{< figure alt="Yo web ui" width=80% src="../resources/Yo_web_ui.png" >}} * **Sending a Yo message via the web interface** @@ -154,7 +154,7 @@ An easy way to see the Legal Names of Corda nodes on the network is to use the p http://(public IP address):(port)/api/yo/peers ``` -{{< figure alt="yo peers2" width=80% zoom="../resources/yo_peers2.png" >}} +{{< figure alt="yo peers2" width=80% src="../resources/yo_peers2.png" >}} * **Viewing Yo messages** @@ -164,7 +164,7 @@ To see Yo! messages sent to a particular node open a browser window and browse t http://(public IP address):(port)/api/yo/yos ``` -{{< figure alt="azure yos" width=80% zoom="../resources/azure_yos.png" >}} +{{< figure alt="azure yos" width=80% src="../resources/azure_yos.png" >}} ## Viewing logs @@ -185,8 +185,8 @@ And navigate to the following directory for system logs (syslog): You can open log files with any text editor. -{{< figure alt="azure vm 10 49" width=80% zoom="../resources/azure_vm_10_49.png" >}} -{{< figure alt="azure syslog" width=80% zoom="../resources/azure_syslog.png" >}} +{{< figure alt="azure vm 10 49" width=80% src="../resources/azure_vm_10_49.png" >}} +{{< figure alt="azure syslog" width=80% src="../resources/azure_syslog.png" >}} ## Join the community diff --git a/content/en/archived-docs/corda-enterprise/4.7/network/cipher-suites.md b/content/en/archived-docs/corda-enterprise/4.7/network/cipher-suites.md index 03f656a7f4a..a0458d6e95c 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/network/cipher-suites.md +++ b/content/en/archived-docs/corda-enterprise/4.7/network/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates](permissioning.md)): -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/archived-docs/corda-enterprise/4.7/network/permissioning.md b/content/en/archived-docs/corda-enterprise/4.7/network/permissioning.md index c88568eec21..1b89aae7e7a 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/network/permissioning.md +++ b/content/en/archived-docs/corda-enterprise/4.7/network/permissioning.md @@ -42,7 +42,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/archived-docs/corda-enterprise/4.7/node/collaborative-recovery/deployment-and-operations.md b/content/en/archived-docs/corda-enterprise/4.7/node/collaborative-recovery/deployment-and-operations.md index 56c58954dd3..7bdc2d5e090 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/node/collaborative-recovery/deployment-and-operations.md +++ b/content/en/archived-docs/corda-enterprise/4.7/node/collaborative-recovery/deployment-and-operations.md @@ -90,7 +90,7 @@ The space complexities are outlined below: You can see a suggested high-level, disaster recovery setup in the diagram below. -{{< figure alt="Suggested Disaster Recovery Setup" width=80% zoom="../../resources/collaborative-recovery/dr-setup.png" >}} +{{< figure alt="Suggested Disaster Recovery Setup" width=80% src="../../resources/collaborative-recovery/dr-setup.png" >}} The exact setup you choose is likely to be influenced by your organisation and business requirements, but the key points are: diff --git a/content/en/archived-docs/corda-enterprise/4.7/node/collaborative-recovery/introduction-cr.md b/content/en/archived-docs/corda-enterprise/4.7/node/collaborative-recovery/introduction-cr.md index 60877ec238c..6c52e50b86f 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/node/collaborative-recovery/introduction-cr.md +++ b/content/en/archived-docs/corda-enterprise/4.7/node/collaborative-recovery/introduction-cr.md @@ -147,7 +147,7 @@ inbound / outbound reconciliations and also supports different throttling techni A high-level, peer-to-peer reconciliation flow is depicted in the diagram below. **LedgerSync** can run multiple reconciliations concurrently, up to the limit configured by the user. -{{< figure alt="Peer-to-Peer Reconciliation Flow" width=80% zoom="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} +{{< figure alt="Peer-to-Peer Reconciliation Flow" width=80% src="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} ### LedgerRecover @@ -170,7 +170,7 @@ supports different types of throttling to prevent accidental abuse of the functi A high-level, peer-to-peer automatic recovery flow is depicted in the diagram below. -{{< figure alt="Peer-to-Peer Automatic Recovery Flow" width=80% zoom="../../resources/collaborative-recovery/automatic-ledger-recover-flow.png" >}} +{{< figure alt="Peer-to-Peer Automatic Recovery Flow" width=80% src="../../resources/collaborative-recovery/automatic-ledger-recover-flow.png" >}} {{< attention >}} Even though the recovery flow contains the word "automatic" in its name, it can only be started manually. @@ -189,7 +189,7 @@ the import has been stopped halfway through. A high-level, peer-to-peer manual recovery flow is depicted in the diagram below. -{{< figure alt="Peer-to-Peer Manual Recovery Flow" width=80% zoom="../../resources/collaborative-recovery/manual-ledger-recover-flow.png" >}} +{{< figure alt="Peer-to-Peer Manual Recovery Flow" width=80% src="../../resources/collaborative-recovery/manual-ledger-recover-flow.png" >}} ### Supported disaster recovery scenarios diff --git a/content/en/archived-docs/corda-enterprise/4.7/node/collaborative-recovery/ledger-sync.md b/content/en/archived-docs/corda-enterprise/4.7/node/collaborative-recovery/ledger-sync.md index e41fe5c3a4c..eed7af6fcc4 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/node/collaborative-recovery/ledger-sync.md +++ b/content/en/archived-docs/corda-enterprise/4.7/node/collaborative-recovery/ledger-sync.md @@ -28,7 +28,7 @@ All reconciliations are added to a bounded execution pool, which is configurable This means the node that requested the reconciliation will be notified if the responding node has transactions that the requesting node does not. The responding node will not be notified if the requesting node has transactions that the responding node does not. -{{< figure alt="Ledger Sync Flow" width=80% zoom="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} +{{< figure alt="Ledger Sync Flow" width=80% src="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} ### Integration with Archiving diff --git a/content/en/archived-docs/corda-enterprise/4.7/node/component-topology.md b/content/en/archived-docs/corda-enterprise/4.7/node/component-topology.md index 612b6319b21..cbfd3f7c4ff 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/node/component-topology.md +++ b/content/en/archived-docs/corda-enterprise/4.7/node/component-topology.md @@ -16,7 +16,7 @@ weight: 30 It is useful to take a high level perspective of the Corda components, especially the various communication protocols that Corda employs in its operations. The diagram below illustrates the various communication protocols used by the Corda Node communicating with peers on the Corda Network. -{{< figure alt="overview" width=80% zoom="../resources/overview.png" >}} +{{< figure alt="overview" width=80% src="../resources/overview.png" >}} Corda Nodes communicate with each other using the asynchronous AMQP/TLS 1.2 protocols. HTTP communication is only used for initial registration of Corda Nodes and sharing the Corda Node address locations by way of the network map. Client applications communicate with Corda Nodes using RPC calls. A Node’s vault is a database that relies on JDBC connection from the Corda Node. When hosting a Corda Node on-premise, it’s important to consider: @@ -31,7 +31,7 @@ When hosting a Corda Node on-premise, it’s important to consider: In any given production deployment of Corda Enterprise, the most common components are the Corda Node, vault, and firewall. -{{< figure alt="nodebridgefloat nbrs" width=80% zoom="../resources/nodebridgefloat_nbrs.png" >}} +{{< figure alt="nodebridgefloat nbrs" width=80% src="../resources/nodebridgefloat_nbrs.png" >}} A typical Node deployment. diff --git a/content/en/archived-docs/corda-enterprise/4.7/node/corda-firewall-component.md b/content/en/archived-docs/corda-enterprise/4.7/node/corda-firewall-component.md index 20493d57cad..bd98269cf4c 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/node/corda-firewall-component.md +++ b/content/en/archived-docs/corda-enterprise/4.7/node/corda-firewall-component.md @@ -140,7 +140,7 @@ Artemis with the node as TLS endpoint and to have the outgoing packets use the i Typically, this should only be used for easy development, or for organisations evaluating on Open Source Corda, where this is the only available option: -{{< figure alt="node embedded bridge" width=80% zoom="/en/images/node_embedded_bridge.png" >}} +{{< figure alt="node embedded bridge" width=80% src="/en/images/node_embedded_bridge.png" >}} ### Node + Combined Bridge/Float (no DMZ) @@ -170,7 +170,7 @@ Then configure an all-in-one bridge to point at this node’s `messagingServerAd {{< /note >}} -{{< figure alt="simple bridge" width=80% zoom="/en/images/simple_bridge.png" >}} +{{< figure alt="simple bridge" width=80% src="/en/images/simple_bridge.png" >}} #### node.conf @@ -238,7 +238,7 @@ key, the tunnel link should use a private set of link specific keys and certific dynamically with the official TLS key when activated via the tunnel and this key will never be stored in the DMZ: {{< /note >}} -{{< figure alt="node bridge float" width=80% zoom="/en/images/node_bridge_float.png" >}} +{{< figure alt="node bridge float" width=80% src="/en/images/node_bridge_float.png" >}} #### node.conf @@ -326,7 +326,7 @@ Some organisations require dynamic outgoing connections to operate via a SOCKS p by adding extra information to the `outboundConfig` section of the bridge process. A simplified example deployment is shown here to highlight the option: -{{< figure alt="socks proxy" width=80% zoom="/en/images/socks_proxy.png" >}} +{{< figure alt="socks proxy" width=80% src="/en/images/socks_proxy.png" >}} #### node.conf @@ -426,7 +426,7 @@ Highlighted in the diagram is the addition of the `haConfig` section to point at addresses in the `alternateArtemisAddresses` to allow node failover and in the `floatAddresses` to point at a pool of DMZ float processes. -{{< figure alt="ha nodes" width=80% zoom="/en/images/ha_nodes.png" >}} +{{< figure alt="ha nodes" width=80% src="/en/images/ha_nodes.png" >}} #### node.conf @@ -563,7 +563,7 @@ It is possible to allow two or more Corda nodes (HA and/or non-HA) handle outgoi an external Artemis messaging broker which can be easily configured using the ha-tool. For more information, please see HA Utilities. While this example is the simplest deployment possible with a shared bridge, any other configuration previously presented can be created. -{{< figure alt="multiple nodes no ha" width=80% zoom="/en/images/multiple_nodes_no_ha.png" >}} +{{< figure alt="multiple nodes no ha" width=80% src="/en/images/multiple_nodes_no_ha.png" >}} #### bank-a-node.conf diff --git a/content/en/archived-docs/corda-enterprise/4.7/node/corda-firewall-configuration-file.md b/content/en/archived-docs/corda-enterprise/4.7/node/corda-firewall-configuration-file.md index 2611fe1a82a..9b079e8bb7b 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/node/corda-firewall-configuration-file.md +++ b/content/en/archived-docs/corda-enterprise/4.7/node/corda-firewall-configuration-file.md @@ -131,14 +131,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -151,7 +151,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/archived-docs/corda-enterprise/4.7/node/deploy/env-prod-test.md b/content/en/archived-docs/corda-enterprise/4.7/node/deploy/env-prod-test.md index 6b87da64d5f..fe8a8e82175 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/node/deploy/env-prod-test.md +++ b/content/en/archived-docs/corda-enterprise/4.7/node/deploy/env-prod-test.md @@ -33,12 +33,12 @@ There are alternative approaches to how these components are deployed. For the p When deploying Corda Enterprise in a testing environment the Node, Bridge, and Float components should be deployed in a non-HA configuration as shown in the following diagram. -{{< figure alt="nonha" width=80% zoom="../../resources/nonha.png" >}} +{{< figure alt="nonha" width=80% src="../../resources/nonha.png" >}} When deploying Corda Enterprise in a production environment, the Node, Bridge, and Float components should be deployed in a high-availability configuration. -{{< figure alt="ha" width=80% zoom="../../resources/ha.png" >}} +{{< figure alt="ha" width=80% src="../../resources/ha.png" >}} ### Deployment details @@ -206,7 +206,7 @@ This is a sample `node.conf` which details a configuration connecting to the Cor In a bank environment there will typically be several layers of security protecting the firms data. -{{< figure alt="cordarch" width=80% zoom="../../resources/cordarch.png" >}} +{{< figure alt="cordarch" width=80% src="../../resources/cordarch.png" >}} *Network Authentication* @@ -220,7 +220,7 @@ In a bank environment there will typically be several layers of security protect * Corda PKI Authentication issued by Corda Network can link the Node and Bridge i.e. the red keys indicated below truststore and sslkeystore * Local PKI Authentication issued by separate CA will link the Bridge and Float i.e the purple keys indicated below trust and Bridge. -{{< figure alt="firewallpki" width=80% zoom="../../resources/firewallpki.png" >}} +{{< figure alt="firewallpki" width=80% src="../../resources/firewallpki.png" >}} The key thing is to look at this from the perspective of a bank implementing these Corda and Local PKI keys. @@ -375,7 +375,7 @@ Administrative logins with the Corda Node happen via ssh whose port is configure The following image may be helpful in ensuring alignment between the Node, Bridge and Float configuration files. -{{< figure alt="CordaFirewallConfigAlign" width=80% zoom="../../resources/CordaFirewallConfigAlign.png" >}} +{{< figure alt="CordaFirewallConfigAlign" width=80% src="../../resources/CordaFirewallConfigAlign.png" >}} {{< note >}} **p2pAddress** reflects the **publicly accessible address**, which may or may not be the Float inboundConfig.listeningAddress. If there is an internet firewall configured in front of the Float then ask the Network Administrator for the public address that routes to the Float’s **listeningAddress**, and use that public address for your **p2pAddress**. diff --git a/content/en/archived-docs/corda-enterprise/4.7/node/deploy/hot-cold-deployment.md b/content/en/archived-docs/corda-enterprise/4.7/node/deploy/hot-cold-deployment.md index d9dbb0bf05b..9cbd9034020 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/node/deploy/hot-cold-deployment.md +++ b/content/en/archived-docs/corda-enterprise/4.7/node/deploy/hot-cold-deployment.md @@ -36,7 +36,7 @@ resources for both **Microsoft Azure** and **Amazon Web Services**. The image be result from following the guide. There will be two Corda Enterprise nodes, one active and the other inactive. Each node will represent the same legal identity inside the Corda network. Both will share a database and a network file system. -{{< figure alt="hot cold" width=80% zoom="../../resources/hot-cold.png" >}} +{{< figure alt="hot cold" width=80% src="../../resources/hot-cold.png" >}} ## Configuring the load balancer diff --git a/content/en/archived-docs/corda-enterprise/4.7/node/node-administration.md b/content/en/archived-docs/corda-enterprise/4.7/node/node-administration.md index bda0e50c3a3..dee51262b40 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/node/node-administration.md +++ b/content/en/archived-docs/corda-enterprise/4.7/node/node-administration.md @@ -242,7 +242,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ### Monitoring via Graphite diff --git a/content/en/archived-docs/corda-enterprise/4.7/node/operating/monitoring-logging.md b/content/en/archived-docs/corda-enterprise/4.7/node/operating/monitoring-logging.md index d6eea4de722..655c6fd9622 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/node/operating/monitoring-logging.md +++ b/content/en/archived-docs/corda-enterprise/4.7/node/operating/monitoring-logging.md @@ -142,7 +142,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ### Monitoring via Graphite diff --git a/content/en/archived-docs/corda-enterprise/4.7/node/operating/node-administration.md b/content/en/archived-docs/corda-enterprise/4.7/node/operating/node-administration.md index 74f87c1edea..f4929b6a79c 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/node/operating/node-administration.md +++ b/content/en/archived-docs/corda-enterprise/4.7/node/operating/node-administration.md @@ -242,7 +242,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ### Monitoring via Graphite diff --git a/content/en/archived-docs/corda-enterprise/4.7/node/operating/node-database-tables.md b/content/en/archived-docs/corda-enterprise/4.7/node/operating/node-database-tables.md index cc16539cacc..467715a238e 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/node/operating/node-database-tables.md +++ b/content/en/archived-docs/corda-enterprise/4.7/node/operating/node-database-tables.md @@ -43,7 +43,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more in [Network map]({{< relref "../../network/network-map.md" >}}). -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -169,7 +169,7 @@ Read more in [Ledger]({{< relref "../../key-concepts-ledger.md" >}}). Read more in [Working with attachments]({{< relref "../../tutorial-attachments.md" >}}) and [Node services]({{< relref "../../node-services.md" >}}). -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -465,7 +465,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -494,7 +494,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/archived-docs/corda-enterprise/4.7/node/pki-guide.md b/content/en/archived-docs/corda-enterprise/4.7/node/pki-guide.md index 1605b6d24a2..549fd3e2335 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/node/pki-guide.md +++ b/content/en/archived-docs/corda-enterprise/4.7/node/pki-guide.md @@ -54,7 +54,7 @@ as they root to the same certificate. Other than that, Corda nodes stay agnostic to the certificate hierarchy (in particular the depth of the certificate hierarchy tree). -{{< figure alt="hierarchy agnostic" width=80% zoom="../resources/hierarchy-agnostic.png" >}} +{{< figure alt="hierarchy agnostic" width=80% src="../resources/hierarchy-agnostic.png" >}} At the time of writing this document, the Corda Network assumes the certificate hierarchy that can be found [here]({{< relref "../../../../../../en/platform/corda/4.7/enterprise/network/permissioning.md" >}}). @@ -69,7 +69,7 @@ The network operator is responsible for certificate issuance and maintenance for at the Identity Manager and Network Map certificates. The rest of the certificate chain (i.e. every certificate below the Identity Manager certificate) falls into node operator responsibility. -{{< figure alt="tls hierarchy" width=80% zoom="../resources/tls-hierarchy.png" >}} +{{< figure alt="tls hierarchy" width=80% src="../resources/tls-hierarchy.png" >}} The certificate revocation list verification applies to the entire chain. This means that every certificate in the chain is going to be validated against the corresponding certificate revocation list during the SSL handshake. Consequently, this means that a node operator is expected to provide and maintain the certificate revocation list for the Node CA. @@ -87,7 +87,7 @@ During the certificate revocation list validation process the trust store is con As an example, let us consider the following certificate hierarchy: -{{< figure alt="example hierarchy" width=80% zoom="../resources/example-hierarchy.png" >}} +{{< figure alt="example hierarchy" width=80% src="../resources/example-hierarchy.png" >}} The certificate hierarchy presented above is currently (as of the time of writing this document) used in the Corda Network. It follows practices applicable for certificate authorities providing a balance between security and simplicity of usage. In this scenario, a network operator wants to create a CA hierarchy where the self-signed Root CA issues a certificate for the Subordinate CA which in turn issues diff --git a/content/en/archived-docs/corda-enterprise/4.7/notary-healthcheck.md b/content/en/archived-docs/corda-enterprise/4.7/notary-healthcheck.md index a1fd37be68d..1806fc1e323 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/notary-healthcheck.md +++ b/content/en/archived-docs/corda-enterprise/4.7/notary-healthcheck.md @@ -171,4 +171,4 @@ monitor notary health via a dashboard or hook up an alerter. As an example, this view on a failing notary check. Note the metrics for *success*, *fail*, *inflight*, and *maxinflightTime* for the notary service and the cluster members on the left hand side. -{{< figure alt="hawtio healthcheck" width=80% zoom="./resources/hawtio-healthcheck.png" >}} +{{< figure alt="hawtio healthcheck" width=80% src="./resources/hawtio-healthcheck.png" >}} diff --git a/content/en/archived-docs/corda-enterprise/4.7/notary/backup-restore.md b/content/en/archived-docs/corda-enterprise/4.7/notary/backup-restore.md index 7888fd80c8b..82683ac5863 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/notary/backup-restore.md +++ b/content/en/archived-docs/corda-enterprise/4.7/notary/backup-restore.md @@ -29,7 +29,7 @@ Additionally, it is critical to have a backup of the Notary Service identity pri The following diagram highlights in blue which storage components should be backed up. -{{< figure alt="storage components" width=80% zoom="../resources/storage-components.png" >}} +{{< figure alt="storage components" width=80% src="../resources/storage-components.png" >}} Note that for regular nodes it is very important to back up the Messaging Broker (Artemis) folder and the local Database, but for HA notary nodes that are purely used for notarisation purposes that is not needed. To summarise: diff --git a/content/en/archived-docs/corda-enterprise/4.7/notary/ha-notary-service-overview.md b/content/en/archived-docs/corda-enterprise/4.7/notary/ha-notary-service-overview.md index 16e65efbce7..94ff4365350 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/notary/ha-notary-service-overview.md +++ b/content/en/archived-docs/corda-enterprise/4.7/notary/ha-notary-service-overview.md @@ -60,7 +60,7 @@ database to store its node state (e.g. its identity information). We can visualise this set-up as follows, with the regular Corda nodes in green, the Corda notary worker nodes in red, and the standard node databases and notary state database replicas in blue. -{{< figure alt="ha notary overview2" width=80% zoom="../resources/ha-notary-overview2.png" >}} +{{< figure alt="ha notary overview2" width=80% src="../resources/ha-notary-overview2.png" >}} Nodes requesting notarisation from a highly-available notary will connect to the notary workers in round-robin fashion. Provided there are multiple notary workers and the notary state database is configured to be highly-available, the overall notary service @@ -73,7 +73,7 @@ In production, R3 recommends running five or more replicas in the notary state d If desired, you can choose to run each database server and its Corda notary worker on the same machine: -{{< figure alt="ha notary colocated" width=80% zoom="../resources/ha-notary-colocated.png" >}} +{{< figure alt="ha notary colocated" width=80% src="../resources/ha-notary-colocated.png" >}} ## Notary configuration diff --git a/content/en/archived-docs/corda-enterprise/4.7/notary/hsm-support.md b/content/en/archived-docs/corda-enterprise/4.7/notary/hsm-support.md index 35d33d3c522..009fdf66d3b 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/notary/hsm-support.md +++ b/content/en/archived-docs/corda-enterprise/4.7/notary/hsm-support.md @@ -14,7 +14,7 @@ weight: 3 ## Overview -{{< figure alt="hsm support" width=80% zoom="../resources/hsm-support.png" >}} +{{< figure alt="hsm support" width=80% src="../resources/hsm-support.png" >}} Two notary workers and their relevant cryptographic keys used for P2P messaging and transaction signing. The red rectangles represent the Corda notary worker services. The distinct identity keys are represented by rectangles in green and yellow and the shared key of the notary service identity is drawn in blue. Their cryptographic keys are held in a single HSM. diff --git a/content/en/archived-docs/corda-enterprise/4.7/operations/deployment/cenm-upgrade.md b/content/en/archived-docs/corda-enterprise/4.7/operations/deployment/cenm-upgrade.md index dcc1ff5d3ff..701314d151b 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/operations/deployment/cenm-upgrade.md +++ b/content/en/archived-docs/corda-enterprise/4.7/operations/deployment/cenm-upgrade.md @@ -409,13 +409,13 @@ Once this has been done the following steps should be followed to upgrade the se For example for the Doorman service: -{{< figure alt="doorman migration" width=80% zoom="/en/images/doorman-migration.png" >}} +{{< figure alt="doorman migration" width=80% src="/en/images/doorman-migration.png" >}} These steps should be followed for both the Doorman and Network Map Services. This process is *non-destructive* - it should leave the old database untouched, only copying the data across to the new databases. Once both services have been migrated via the above process they will be fully functional: -{{< figure alt="separated services" width=80% zoom="/en/images/separated-services.png" >}} +{{< figure alt="separated services" width=80% src="/en/images/separated-services.png" >}} ### Other required changes diff --git a/content/en/archived-docs/corda-enterprise/4.7/operations/deployment/firewall-deployment.md b/content/en/archived-docs/corda-enterprise/4.7/operations/deployment/firewall-deployment.md index b5336890956..eead2f51061 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/operations/deployment/firewall-deployment.md +++ b/content/en/archived-docs/corda-enterprise/4.7/operations/deployment/firewall-deployment.md @@ -130,14 +130,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -150,7 +150,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/introduction.md b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/introduction.md index 4bace3a6171..57ec7ff684a 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/introduction.md +++ b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/introduction.md @@ -109,7 +109,7 @@ The driving app sits outside the network and connects to the JMeter servers thro measuring the throughput of a node, the test definition instructs all JMeter servers to open RPC connections to one node, thus saturating the RPC handler and driving the node as hard as possible. The test might invoke a flow that can be completed locally (for example, cash issuance) or it might require exchanging P2P messages with other nodes (for example, cash payment). -{{< figure alt="jmeter network overview" width=80% zoom="../resources/jmeter-network-overview.png" >}} +{{< figure alt="jmeter network overview" width=80% src="../resources/jmeter-network-overview.png" >}} ## Performance Tests diff --git a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/jmeter-samplers.md b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/jmeter-samplers.md index d81fc70999b..e6e816ee764 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/jmeter-samplers.md +++ b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/jmeter-samplers.md @@ -66,7 +66,7 @@ server, not the client machine. * `minimumNodePlatformVersion`: the minimum platform version that the JMeter client will require from the Corda nodes. It defaults to 4, which can be used to test with Corda 4.0 nodes or later. * `username`: the RPC user name of the Corda node. * `password`: the RPC password of the Corda node. -{{< figure alt="empty flow sampler" width=80% zoom="../resources/empty-flow-sampler.png" >}} +{{< figure alt="empty flow sampler" width=80% src="../resources/empty-flow-sampler.png" >}} * `CashIssueSampler`: this sampler client has the class name `com.r3.corda.jmeter.CashIssueSampler` and starts the flow `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueFlow`. This flow self-issues 1.1 billion cash tokens on the node it is running on, and stores it in the vault. In addition to the common properties described for `EmptyFlowSampler` above, this sampler client also requires: * `notaryName`: the X500 name of the notary that is acceptable to transfer cash tokens issued via this sampler. Issuing tokens does not need to be notarised, and therefore invoking this sampler does not create traffic to the notary. However, the notary is stored as part of the cash state and must be valid to do anything else with the cash state, therefore this sampler checks the notary identity against the network parameters of the node. * `CashIssueAndPaySampler`: this sampler client has the classname `com.r3.corda.jmeter.CashIssueAndPaySampler` and, depending on its parameters, it can start either of these flows - `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndPaymentFlow` or `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndpaymentNoSelection`. Either way it issues 2 million dollars in tokens and then transfers the sum to a configurable other node, thus invoking the full vault access, peer-to-peer communication and notarisation cycle. In addition to the parameters required for `CashIssueSampler`, this sampler also requires: diff --git a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/jmeter-testplans.md b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/jmeter-testplans.md index 6ec86220b9c..09d903a906c 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/jmeter-testplans.md +++ b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/jmeter-testplans.md @@ -25,12 +25,12 @@ The testplan is a hierarchy of configuration elements. The only elements used in *Variables*, *Thread Groups*, *Samplers* and *Listeners*. Rather than creating a new testplan from scratch, it might a good idea to take a copy of one of the provided example test plans and modify that. -{{< figure alt="jmeter testplan" width=80% zoom="../resources/jmeter-testplan.png" >}} +{{< figure alt="jmeter testplan" width=80% src="../resources/jmeter-testplan.png" >}} A variables element defines key/value pairs that can be used in all following following elements instead of string literals. They can be referenced by using a `$` sign and curly braces, e.g. `${varName}`. -{{< figure alt="variables" width=80% zoom="../resources/variables.png" >}} +{{< figure alt="variables" width=80% src="../resources/variables.png" >}} A thread group collects a set of actions that form one step in the test plan. All elements within a thread group diff --git a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/performance-results.md b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/performance-results.md index 5938b937480..0fb85bd6978 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/performance-results.md +++ b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/performance-results.md @@ -40,7 +40,7 @@ the time of Corda Enterprise Edition 4 release). This is with each node running running **Microsoft SQL Server**. Similar results were obtained against the other supported databases. -{{< figure alt="ce4 comparison chart" width=80% zoom="/en/images/ce4-comparison-chart.png" >}} +{{< figure alt="ce4 comparison chart" width=80% src="/en/images/ce4-comparison-chart.png" >}} Figure 1 @@ -52,7 +52,7 @@ varies with the number of those payments combined together. This can be useful be a technique for even greater throughput. -{{< figure alt="states per second" width=80% zoom="/en/images/states-per-second.png" >}} +{{< figure alt="states per second" width=80% src="/en/images/states-per-second.png" >}} Figure 2 @@ -65,7 +65,7 @@ of Figure 3 were achieved using Corda Enterprise 3.0 on **Microsoft Azure** virt with minimal latency between the node VM and the database server VM. -{{< figure alt="comparison chart" width=80% zoom="/en/images/comparison-chart.png" >}} +{{< figure alt="comparison chart" width=80% src="/en/images/comparison-chart.png" >}} Figure 3 @@ -303,7 +303,7 @@ All these machines were 24 core (48 hyper-threads), based on 2x Intel Xeon E5-26 The first test performed was focused on the latency aspect. Load was generated from a single client initialised in a machine that was separate from the ones hosting the Corda nodes and their databases. The load consisted of a pre-defined number of flows (400) that were executed one after the other sequentially. Each one of those flows was initiated on the central exchange node, which was responsible for collecting signatures from all the parties involved and for finalising the transaction. Each of those flows performed a swap of two states between every pair of nodes, thus leading to a Corda transaction with 10 input and 10 output states. During the test setup, the necessary amount of states was initially issued and each one of those states would be swapped once during the test. In order to also measure the impact of transaction resolution, during the test setup each of these states was transferred bilaterally between the nodes in each pair ten times, thus generating a backchain of depth 10. This meant that during every Corda transaction, each node would have to resolve the backchain of the states belonging to the other pairs - so each node would have to resolve 80 states (8 nodes x 10 states each). In order to also measure the scaling with regard to the number of nodes, the exact same test was repeated with a varying number of participants, starting from 4 nodes and going up to 10. The test was also repeated three times with Corda Enterprise versions 4.3, 4.4, and 4.5. The goal was to isolate the benefits from bulk transaction resolution, introduced in version 4.4, and parallelised flows (`CollectSignaturesFlow` / `FinalityFlow`), introduced in version 4.5. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average latency of the flow that performed the asset swap in milliseconds. -{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.3 shows an exponential increase in the latency of the flow as the number of nodes that participate in the transaction is increased. This can be attributed to the following two reasons. Firstly, during the tests the exchange node was performing the `CollectSignaturesFlow` and `FinalityFlow` flows sequentially across the involved nodes, so the more nodes these flows had to iterate over, the more time it took. Secondly, these flows have the capability to trigger the execution of transaction resolution if they identify states for which the node is missing the provenance chain. In Corda Enterprise Edition 4.3, transaction resolution is not performed in bulk - it is performed one state at a time. As a result, every additional node causes a significant amount of extra work to be done. @@ -314,7 +314,7 @@ The main observations from the tests follow below: The second test was focused on the throughput aspect. Load was generated from multiple clients initialised on the machines that were hosting the Corda nodes, which were acting as JMeter servers orchestrated by a JMeter client running on a separate machine. The goal was to saturate the participating Corda nodes and to prevent the single client from becoming the bottleneck. During the test setup, each client issued one state to every node. Each client was then performing one flow at a time, swapping these states between the participating nodes. No backchain was generated as part of this test. As a result, the test was executed only between Corda Enterprise Edition 4.3 and Corda Enterprise Edition 4.5, and with a varying number of nodes ranging from 2 up to 10. Each of the machines driving the load was using 120 concurrent clients, which summed up to 480 concurrent clients in total. Additional measurements were performed with a varying number of clients, in order to ensure that this was the optimal number of clients to saturate the nodes without overloading them. Since the throughput was different depending on the number of participating nodes, the total number of requests was also adjusted accordingly in order to get roughly the same total duration of approximately 20 minutes. In all the scenarios, it was confirmed that the nodes had reached a stable state when the test ended. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average throughput measured in the number of flows completed per second. -{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.5 can achieve a significantly higher throughput when compared to Corda Enterprise Edition 4.3. This can be attributed to the following factors: @@ -336,9 +336,9 @@ Five different variations were tested, as follows: The purpose of this last test was to investigate the effects of these options in both throughput and latency because some of these options introduce trade-offs between these two aspects. To this end, the tests described earlier in this analysis were repeated using the variations listed above. For the latency measurements, 10 nodes were used because, thanks to the low load, there was no expectation for any big interference between nodes on the same machine. For the throughput measurements, only 4 nodes were used in order to avoid any interference between nodes on the same machine due to the high load. The results are shown in the diagrams below - the *x* axis contains the variations used, and the *y* axis shows the average throughput and latency achieved with each variation along with error bars indicating the standard deviation. -{{< figure alt="CE 4.5 variants latency comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_latency.png" >}} +{{< figure alt="CE 4.5 variants latency comparison chart" width=80% src="../resources/performance-testing/4-5_variants_latency.png" >}} -{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_throughput.png" >}} +{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% src="../resources/performance-testing/4-5_variants_throughput.png" >}} The main observations from the test are as follows: * Disabling compression leads to lower throughput and higher latency. This is expected because compression introduces a trade-off between CPU and network bandwidth utilisation and in most cases the network would prove to be a bigger bottleneck. diff --git a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/practical-considerations.md b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/practical-considerations.md index 37d02230a8f..9f210161dc1 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/practical-considerations.md +++ b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/practical-considerations.md @@ -94,7 +94,7 @@ To collect the output of a JMeter performance run, we need to add listeners to t This listener just lists all the runs that have been completed, one run per row, stating the thread name, sampler label, the sample time in milliseconds, the result status and the latency in milliseconds, among other (usually less useful) fields. -{{< figure alt="jmeter results table" width=80% zoom="../resources/jmeter-results-table.png" >}} +{{< figure alt="jmeter results table" width=80% src="../resources/jmeter-results-table.png" >}} This view is particularly useful when trying out any changes (new flow, new sampler, new installation) to see if it is working at all. The potential outcomes are: @@ -123,7 +123,7 @@ This listener aggregates all the runs for each thread group and the whole test p It also allows plotting these statistics in basic charts and to save the results as a csv file. This is what we use for looking at the performance results on a day to day basis. -{{< figure alt="jmeter results aggregate" width=80% zoom="../resources/jmeter-results-aggregate.png" >}} +{{< figure alt="jmeter results aggregate" width=80% src="../resources/jmeter-results-aggregate.png" >}} This listener has one line for each sampler being run as part of the test plan, and a total line summing up/averaging the results for the whole test plan. diff --git a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/r3-performance-runs.md b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/r3-performance-runs.md index ff59fc46982..6f000f39620 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/r3-performance-runs.md +++ b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/r3-performance-runs.md @@ -32,7 +32,7 @@ The performance network sits behind a firewall that allows incoming connections within the network can connect to each other on a range of ports (Corda Remote Procedure Call (RPC), Corda peer to peer connection (P2P) and JDBC connections to various database servers are all allowed). -{{< figure alt="performance cluster" width=80% zoom="../resources/performance-cluster.png" >}} +{{< figure alt="performance cluster" width=80% src="../resources/performance-cluster.png" >}} A Corda JMeter server instance is running on all 4 nodes and on the notary server. The JMeter client connects to the JMeter server instances via SSH tunnels. As the JMeter servers run within the firewalled network, they are free to diff --git a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/running-jmeter-corda.md b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/running-jmeter-corda.md index cc614e26e0b..189f5dc2aab 100644 --- a/content/en/archived-docs/corda-enterprise/4.7/performance-testing/running-jmeter-corda.md +++ b/content/en/archived-docs/corda-enterprise/4.7/performance-testing/running-jmeter-corda.md @@ -54,7 +54,7 @@ interactively either locally or remotely, and view results. The UI has a set of quickly create or load a testplan, control local or remote test runs, and clear any test results collected so far. The latter is particularly important when looking at averages, as old data might skew the results being looked at. -{{< figure alt="jmeter buttons" width=80% zoom="../resources/jmeter-buttons.png" >}} +{{< figure alt="jmeter buttons" width=80% src="../resources/jmeter-buttons.png" >}} The *clear current view* button only clears the data in the currently viewed output collector - if a test plan has several output listeners defined (as in the example above, we have *Aggregate Graph*, *Graph Results* and *View Results in Table*), any collector not currently selected is not affected. *Clear all data* will clear the results from all collectors. diff --git a/content/en/archived-docs/corda-os/4.0/building-the-docs.md b/content/en/archived-docs/corda-os/4.0/building-the-docs.md index 04c84a31b49..cbb620efbba 100644 --- a/content/en/archived-docs/corda-os/4.0/building-the-docs.md +++ b/content/en/archived-docs/corda-os/4.0/building-the-docs.md @@ -78,7 +78,7 @@ Or if you want to use Docker: As a result, there will be an extra icon in the title bar of your local docs site, which should open the current page in Visual Studio Code: -{{< figure alt="Visual Studio Code" width=80% zoom="/en/images/hugo-vscode-page-edit.png" >}} +{{< figure alt="Visual Studio Code" width=80% src="/en/images/hugo-vscode-page-edit.png" >}} ## Edit web pages directly in Atom diff --git a/content/en/archived-docs/corda-os/4.1/building-the-docs.md b/content/en/archived-docs/corda-os/4.1/building-the-docs.md index 56abb11954a..93af2af13cf 100644 --- a/content/en/archived-docs/corda-os/4.1/building-the-docs.md +++ b/content/en/archived-docs/corda-os/4.1/building-the-docs.md @@ -78,7 +78,7 @@ Or if you want to use Docker: As a result, there will be an extra icon in the title bar of your local docs site, which should open the current page in Visual Studio Code: -{{< figure alt="Visual Studio Code" width=80% zoom="/en/images/hugo-vscode-page-edit.png" >}} +{{< figure alt="Visual Studio Code" width=80% src="/en/images/hugo-vscode-page-edit.png" >}} ## Edit web pages directly in Atom diff --git a/content/en/archived-docs/corda-os/4.3/building-the-docs.md b/content/en/archived-docs/corda-os/4.3/building-the-docs.md index 7eda567faf1..c7ce0f8c339 100644 --- a/content/en/archived-docs/corda-os/4.3/building-the-docs.md +++ b/content/en/archived-docs/corda-os/4.3/building-the-docs.md @@ -78,7 +78,7 @@ Or if you want to use Docker: As a result, there will be an extra icon in the title bar of your local docs site, which should open the current page in Visual Studio Code: -{{< figure alt="Visual Studio Code" width=80% zoom="/en/images/hugo-vscode-page-edit.png" >}} +{{< figure alt="Visual Studio Code" width=80% src="/en/images/hugo-vscode-page-edit.png" >}} ## Edit web pages directly in Atom diff --git a/content/en/archived-docs/corda-os/4.4/building-the-docs.md b/content/en/archived-docs/corda-os/4.4/building-the-docs.md index 8933c1edb74..a5fcc1e73f9 100644 --- a/content/en/archived-docs/corda-os/4.4/building-the-docs.md +++ b/content/en/archived-docs/corda-os/4.4/building-the-docs.md @@ -83,7 +83,7 @@ Or if you want to use Docker: As a result, there will be an extra icon in the title bar of your local docs site, which should open the current page in Visual Studio Code: -{{< figure alt="Visual Studio Code" width=80% zoom="/en/images/hugo-vscode-page-edit.png" >}} +{{< figure alt="Visual Studio Code" width=80% src="/en/images/hugo-vscode-page-edit.png" >}} ## Edit web pages directly in Atom diff --git a/content/en/archived-docs/corda-os/4.4/hello-world-flow.md b/content/en/archived-docs/corda-os/4.4/hello-world-flow.md index 5e247724906..e93b4622eff 100644 --- a/content/en/archived-docs/corda-os/4.4/hello-world-flow.md +++ b/content/en/archived-docs/corda-os/4.4/hello-world-flow.md @@ -244,7 +244,7 @@ You’ll build your transaction proposal in two steps: Our transaction will have the following structure: -{{< figure alt="simple tutorial transaction" width=80% zoom="/en/images/simple-tutorial-transaction.png" >}} +{{< figure alt="simple tutorial transaction" width=80% src="/en/images/simple-tutorial-transaction.png" >}} * The output `IOUState` on the right represents the state you will be adding to the ledger. As you can see, there are diff --git a/content/en/archived-docs/corda-os/4.4/hello-world-introduction.md b/content/en/archived-docs/corda-os/4.4/hello-world-introduction.md index 673b57ec30d..ba6688bb4a7 100644 --- a/content/en/archived-docs/corda-os/4.4/hello-world-introduction.md +++ b/content/en/archived-docs/corda-os/4.4/hello-world-introduction.md @@ -70,7 +70,7 @@ For a state, you will use the `IOUState`, representing an IOU. It will contain t `IOUState` as follows: -{{< figure alt="tutorial state" width=80% zoom="/en/images/tutorial-state.png" >}} +{{< figure alt="tutorial state" width=80% src="/en/images/tutorial-state.png" >}} ### IOUFlow @@ -79,7 +79,7 @@ For a flow, you will use the `IOUFlow`. This flow will completely automate the p steps: -{{< figure alt="simple tutorial flow" width=80% zoom="/en/images/simple-tutorial-flow.png" >}} +{{< figure alt="simple tutorial flow" width=80% src="/en/images/simple-tutorial-flow.png" >}} ### IOUContract diff --git a/content/en/archived-docs/corda-os/4.4/hello-world-running.md b/content/en/archived-docs/corda-os/4.4/hello-world-running.md index 021c241d7df..100ad614807 100644 --- a/content/en/archived-docs/corda-os/4.4/hello-world-running.md +++ b/content/en/archived-docs/corda-os/4.4/hello-world-running.md @@ -118,7 +118,7 @@ This will start a terminal window for each node. Give each node a moment to star the message “Welcome to the Corda interactive shell.”. -{{< figure alt="running node" width=80% zoom="/en/images/running_node.png" >}} +{{< figure alt="running node" width=80% src="/en/images/running_node.png" >}} ## Interacting with the nodes diff --git a/content/en/archived-docs/corda-os/4.5/building-the-docs.md b/content/en/archived-docs/corda-os/4.5/building-the-docs.md index 5f82a0e0cad..e4099b83c42 100644 --- a/content/en/archived-docs/corda-os/4.5/building-the-docs.md +++ b/content/en/archived-docs/corda-os/4.5/building-the-docs.md @@ -80,7 +80,7 @@ Or if you want to use Docker: As a result, there will be an extra icon in the title bar of your local docs site, which should open the current page in Visual Studio Code: -{{< figure alt="Visual Studio Code" width=80% zoom="/en/images/hugo-vscode-page-edit.png" >}} +{{< figure alt="Visual Studio Code" width=80% src="/en/images/hugo-vscode-page-edit.png" >}} ## Edit web pages directly in Atom diff --git a/content/en/archived-docs/corda-os/4.5/hello-world-flow.md b/content/en/archived-docs/corda-os/4.5/hello-world-flow.md index 9635a44badd..1ba111a4af2 100644 --- a/content/en/archived-docs/corda-os/4.5/hello-world-flow.md +++ b/content/en/archived-docs/corda-os/4.5/hello-world-flow.md @@ -241,7 +241,7 @@ You’ll build your transaction proposal in two steps: Our transaction will have the following structure: -{{< figure alt="simple tutorial transaction" width=80% zoom="/en/images/simple-tutorial-transaction.png" >}} +{{< figure alt="simple tutorial transaction" width=80% src="/en/images/simple-tutorial-transaction.png" >}} * The output `IOUState` on the right represents the state you will be adding to the ledger. As you can see, there are diff --git a/content/en/archived-docs/corda-os/4.5/hello-world-introduction.md b/content/en/archived-docs/corda-os/4.5/hello-world-introduction.md index 1057fd67861..9273869ec89 100644 --- a/content/en/archived-docs/corda-os/4.5/hello-world-introduction.md +++ b/content/en/archived-docs/corda-os/4.5/hello-world-introduction.md @@ -67,7 +67,7 @@ For a state, you will use the `IOUState`, representing an IOU. It will contain t `IOUState` as follows: -{{< figure alt="tutorial state" width=80% zoom="/en/images/tutorial-state.png" >}} +{{< figure alt="tutorial state" width=80% src="/en/images/tutorial-state.png" >}} ### IOUFlow @@ -76,7 +76,7 @@ For a flow, you will use the `IOUFlow`. This flow will completely automate the p steps: -{{< figure alt="simple tutorial flow" width=80% zoom="/en/images/simple-tutorial-flow.png" >}} +{{< figure alt="simple tutorial flow" width=80% src="/en/images/simple-tutorial-flow.png" >}} ### IOUContract diff --git a/content/en/archived-docs/corda-os/4.5/hello-world-running.md b/content/en/archived-docs/corda-os/4.5/hello-world-running.md index 303b0c5fa33..cfe18146d07 100644 --- a/content/en/archived-docs/corda-os/4.5/hello-world-running.md +++ b/content/en/archived-docs/corda-os/4.5/hello-world-running.md @@ -115,7 +115,7 @@ This will start a terminal window for each node. Give each node a moment to star the message “Welcome to the Corda interactive shell.”. -{{< figure alt="running node" width=80% zoom="/en/images/running_node.png" >}} +{{< figure alt="running node" width=80% src="/en/images/running_node.png" >}} ## Interacting with the nodes diff --git a/content/en/archived-docs/corda-os/4.6/api-core-types.md b/content/en/archived-docs/corda-os/4.6/api-core-types.md index 793ae4a7b3a..ee29deb68e8 100644 --- a/content/en/archived-docs/corda-os/4.6/api-core-types.md +++ b/content/en/archived-docs/corda-os/4.6/api-core-types.md @@ -65,11 +65,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="/en/images/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="/en/images/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="/en/images/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="/en/images/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/archived-docs/corda-os/4.6/api-flows.md b/content/en/archived-docs/corda-os/4.6/api-flows.md index 737156bb116..da3fed13bb2 100644 --- a/content/en/archived-docs/corda-os/4.6/api-flows.md +++ b/content/en/archived-docs/corda-os/4.6/api-flows.md @@ -72,7 +72,7 @@ In our flow, the Initiator flow class will be doing the majority of the work: We can visualize the work performed by initiator as follows: -{{< figure alt="flow overview" width=80% zoom="/en/images/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="/en/images/flow-overview.png" >}} ### Responder diff --git a/content/en/archived-docs/corda-os/4.6/api-states.md b/content/en/archived-docs/corda-os/4.6/api-states.md index 8c864445848..88838397053 100644 --- a/content/en/archived-docs/corda-os/4.6/api-states.md +++ b/content/en/archived-docs/corda-os/4.6/api-states.md @@ -93,7 +93,7 @@ the total amount held that is important, rather than the actual units held. We can picture the hierarchy as follows: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/archived-docs/corda-os/4.6/building-the-docs.md b/content/en/archived-docs/corda-os/4.6/building-the-docs.md index 870fdcb6c33..840f45d8af9 100644 --- a/content/en/archived-docs/corda-os/4.6/building-the-docs.md +++ b/content/en/archived-docs/corda-os/4.6/building-the-docs.md @@ -80,7 +80,7 @@ Or if you want to use Docker: As a result, there will be an extra icon in the title bar of your local docs site, which should open the current page in Visual Studio Code: -{{< figure alt="Visual Studio Code" width=80% zoom="/en/images/hugo-vscode-page-edit.png" >}} +{{< figure alt="Visual Studio Code" width=80% src="/en/images/hugo-vscode-page-edit.png" >}} ## Edit web pages directly in Atom diff --git a/content/en/archived-docs/corda-os/4.6/cheat-sheet.md b/content/en/archived-docs/corda-os/4.6/cheat-sheet.md index be752d5c975..bf7300adc71 100644 --- a/content/en/archived-docs/corda-os/4.6/cheat-sheet.md +++ b/content/en/archived-docs/corda-os/4.6/cheat-sheet.md @@ -16,5 +16,5 @@ title: Cheat sheet A “cheat sheet” summarizing the key Corda types. A PDF version is downloadable [here](/en/pdf/corda-cheat-sheet.pdf). -{{< figure alt="cheatsheet" width=80% zoom="/en/images/cheatsheet.jpg" >}} +{{< figure alt="cheatsheet" width=80% src="/en/images/cheatsheet.jpg" >}} diff --git a/content/en/archived-docs/corda-os/4.6/cipher-suites.md b/content/en/archived-docs/corda-os/4.6/cipher-suites.md index a3edfca26d5..39a27adf6cc 100644 --- a/content/en/archived-docs/corda-os/4.6/cipher-suites.md +++ b/content/en/archived-docs/corda-os/4.6/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates](permissioning.md)): -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/archived-docs/corda-os/4.6/contract-irs.md b/content/en/archived-docs/corda-os/4.6/contract-irs.md index bbf65ba4873..8174f703d1c 100644 --- a/content/en/archived-docs/corda-os/4.6/contract-irs.md +++ b/content/en/archived-docs/corda-os/4.6/contract-irs.md @@ -48,7 +48,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="/en/images/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="/en/images/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/archived-docs/corda-os/4.6/cordapp-advanced-concepts.md b/content/en/archived-docs/corda-os/4.6/cordapp-advanced-concepts.md index 5c3bfcae74d..818355e5131 100644 --- a/content/en/archived-docs/corda-os/4.6/cordapp-advanced-concepts.md +++ b/content/en/archived-docs/corda-os/4.6/cordapp-advanced-concepts.md @@ -73,7 +73,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/archived-docs/corda-os/4.6/cordapp-overview.md b/content/en/archived-docs/corda-os/4.6/cordapp-overview.md index b964d6d6a72..4cb5474ebf6 100644 --- a/content/en/archived-docs/corda-os/4.6/cordapp-overview.md +++ b/content/en/archived-docs/corda-os/4.6/cordapp-overview.md @@ -22,7 +22,7 @@ CorDapps (Corda Distributed Applications) are distributed applications that run CorDapp is to allow nodes to reach agreement on updates to the ledger. They achieve this goal by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="/en/images/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="/en/images/node-diagram.png" >}} {{< note >}} When designing your CorDapp, you may want to consider using the [CorDapp Design Language](../../../../tools/cdl/cdl-overview.md) to structure and organise your designs. This can be especially helpful for complex CorDapps. diff --git a/content/en/archived-docs/corda-os/4.6/financial-model.md b/content/en/archived-docs/corda-os/4.6/financial-model.md index fb0af900da9..af10580b97c 100644 --- a/content/en/archived-docs/corda-os/4.6/financial-model.md +++ b/content/en/archived-docs/corda-os/4.6/financial-model.md @@ -93,7 +93,7 @@ countable (in cents), barrels of West Texas crude are fungible and countable (oi container), shares of the same class in a specific company are fungible and countable, and so on. The following diagram illustrates the complete Contract State hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Note there are currently two packages, a core library and a finance model specific library. Developers may re-use or extend the Finance types directly or write their own by extending the base types from the Core library. diff --git a/content/en/archived-docs/corda-os/4.6/hello-world-flow.md b/content/en/archived-docs/corda-os/4.6/hello-world-flow.md index 1325305e89a..142e2e867d6 100644 --- a/content/en/archived-docs/corda-os/4.6/hello-world-flow.md +++ b/content/en/archived-docs/corda-os/4.6/hello-world-flow.md @@ -241,7 +241,7 @@ You’ll build your transaction proposal in two steps: Our transaction will have the following structure: -{{< figure alt="simple tutorial transaction" width=80% zoom="/en/images/simple-tutorial-transaction.png" >}} +{{< figure alt="simple tutorial transaction" width=80% src="/en/images/simple-tutorial-transaction.png" >}} * The output `IOUState` on the right represents the state you will be adding to the ledger. As you can see, there are diff --git a/content/en/archived-docs/corda-os/4.6/hello-world-introduction.md b/content/en/archived-docs/corda-os/4.6/hello-world-introduction.md index fad30c73236..7b871bde122 100644 --- a/content/en/archived-docs/corda-os/4.6/hello-world-introduction.md +++ b/content/en/archived-docs/corda-os/4.6/hello-world-introduction.md @@ -67,7 +67,7 @@ For a state, you will use the `IOUState`, representing an IOU. It will contain t `IOUState` as follows: -{{< figure alt="tutorial state" width=80% zoom="/en/images/tutorial-state.png" >}} +{{< figure alt="tutorial state" width=80% src="/en/images/tutorial-state.png" >}} ### IOUFlow @@ -76,7 +76,7 @@ For a flow, you will use the `IOUFlow`. This flow will completely automate the p steps: -{{< figure alt="simple tutorial flow" width=80% zoom="/en/images/simple-tutorial-flow.png" >}} +{{< figure alt="simple tutorial flow" width=80% src="/en/images/simple-tutorial-flow.png" >}} ### IOUContract diff --git a/content/en/archived-docs/corda-os/4.6/hello-world-running.md b/content/en/archived-docs/corda-os/4.6/hello-world-running.md index aac9fa3420d..18b8257bbd4 100644 --- a/content/en/archived-docs/corda-os/4.6/hello-world-running.md +++ b/content/en/archived-docs/corda-os/4.6/hello-world-running.md @@ -115,7 +115,7 @@ This will start a terminal window for each node. Give each node a moment to star the message “Welcome to the Corda interactive shell.”. -{{< figure alt="running node" width=80% zoom="/en/images/running_node.png" >}} +{{< figure alt="running node" width=80% src="/en/images/running_node.png" >}} ## Interacting with the nodes diff --git a/content/en/archived-docs/corda-os/4.6/key-concepts-consensus.md b/content/en/archived-docs/corda-os/4.6/key-concepts-consensus.md index 6626c33f607..8b9c5bab466 100644 --- a/content/en/archived-docs/corda-os/4.6/key-concepts-consensus.md +++ b/content/en/archived-docs/corda-os/4.6/key-concepts-consensus.md @@ -53,7 +53,7 @@ transferring us a treasury bond. We can only be sure that the bond transfer is v The only way to be sure of both conditions is to walk the transaction’s chain. We can visualize this process as follows: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a given party may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer(s). The transaction proposer(s) will always have the full transaction chain, since they would have requested it when @@ -70,7 +70,7 @@ proposals: This is a problem because, although both transactions will achieve validity consensus, Bob has managed to “double-spend” his USD to get double the amount of GBP and EUR. We can visualize this as follows: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/archived-docs/corda-os/4.6/key-concepts-contracts.md b/content/en/archived-docs/corda-os/4.6/key-concepts-contracts.md index f981c2c9ecf..44c0b8c00ae 100644 --- a/content/en/archived-docs/corda-os/4.6/key-concepts-contracts.md +++ b/content/en/archived-docs/corda-os/4.6/key-concepts-contracts.md @@ -43,7 +43,7 @@ valid We can picture this situation as follows: -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code has access to the full capabilities of the language, including: diff --git a/content/en/archived-docs/corda-os/4.6/key-concepts-djvm.md b/content/en/archived-docs/corda-os/4.6/key-concepts-djvm.md index 677c7862f10..9e98d105a64 100644 --- a/content/en/archived-docs/corda-os/4.6/key-concepts-djvm.md +++ b/content/en/archived-docs/corda-os/4.6/key-concepts-djvm.md @@ -76,7 +76,7 @@ severity `ERROR` will prevent execution. The sandbox has a configuration that applies to the execution of a specific runnable. This configuration, on a higher level, contains a set of rules, definition providers and emitters. -{{< figure alt="djvm overview" width=80% zoom="/en/images/djvm-overview.png" >}} +{{< figure alt="djvm overview" width=80% src="/en/images/djvm-overview.png" >}} The set of rules is what defines the constraints posed on the runtime environment. A rule can act on three different levels, namely on a type-, member- or instruction-level. The set of rules get processed and validated by the `RuleValidator` prior to execution. diff --git a/content/en/archived-docs/corda-os/4.6/key-concepts-ecosystem.md b/content/en/archived-docs/corda-os/4.6/key-concepts-ecosystem.md index 7f3f63f2c30..177bea22139 100644 --- a/content/en/archived-docs/corda-os/4.6/key-concepts-ecosystem.md +++ b/content/en/archived-docs/corda-os/4.6/key-concepts-ecosystem.md @@ -29,7 +29,7 @@ title: Network A Corda network is a peer-to-peer network of **nodes**. Each node represents a legal entity, and each runs the Corda software (an instance of Corda and one or more Corda applications, known as **CorDapps**). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} All communication between nodes is point-to-point and encrypted using transport-layer security. This means that data is shared only on a need-to-know basis. There are **no global broadcasts**. diff --git a/content/en/archived-docs/corda-os/4.6/key-concepts-flows.md b/content/en/archived-docs/corda-os/4.6/key-concepts-flows.md index c70e6211c62..c5a19d87431 100644 --- a/content/en/archived-docs/corda-os/4.6/key-concepts-flows.md +++ b/content/en/archived-docs/corda-os/4.6/key-concepts-flows.md @@ -36,7 +36,7 @@ what order. Here is a visualisation of the process of agreeing a simple ledger update between Alice and Bob: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -45,7 +45,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is the sequence of flow steps involved in the simple ledger update above: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/archived-docs/corda-os/4.6/key-concepts-ledger.md b/content/en/archived-docs/corda-os/4.6/key-concepts-ledger.md index 9b7a47468d0..99c632f824f 100644 --- a/content/en/archived-docs/corda-os/4.6/key-concepts-ledger.md +++ b/content/en/archived-docs/corda-os/4.6/key-concepts-ledger.md @@ -37,7 +37,7 @@ The facts that a node knows about are those that it is involved with. For exampl Example: A network with five nodes, where each numbered circle on an intersection represents a fact shared between two or more nodes. -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} The preceding Venn diagram represents 5 nodes (Alice, Bob, Carl, Demi and Ed) as sets. Where the sets overlap are shared facts, such as those known by both Alice and Bob (1 and 7). Notably, in this Venn diagram, Alice only shares facts with Bob. Alice does not share facts with any of Carl, Demi or Ed. @@ -61,7 +61,7 @@ In the previous diagram, we could see that although Carl, Demi and Ed are aware You can think of this vault as being a database or simple table. -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} Where the rows are shared between nodes (facts 1 and 7 in this example), these are shared facts. Corda guarantees that whenever one of these facts is shared by multiple nodes on the network, it evolves in lockstep in the database of every node that is aware of it. This means that Alice and Bob will both see an **exactly identical version** of shared facts 1 and 7. diff --git a/content/en/archived-docs/corda-os/4.6/key-concepts-node.md b/content/en/archived-docs/corda-os/4.6/key-concepts-node.md index b1c4f7c6712..58f75a3b2fd 100644 --- a/content/en/archived-docs/corda-os/4.6/key-concepts-node.md +++ b/content/en/archived-docs/corda-os/4.6/key-concepts-node.md @@ -37,7 +37,7 @@ CorDapps. We can visualize the node’s internal architecture as follows: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: * A persistence layer for storing data diff --git a/content/en/archived-docs/corda-os/4.6/key-concepts-states.md b/content/en/archived-docs/corda-os/4.6/key-concepts-states.md index 63960073dd5..ea065427db8 100644 --- a/content/en/archived-docs/corda-os/4.6/key-concepts-states.md +++ b/content/en/archived-docs/corda-os/4.6/key-concepts-states.md @@ -36,7 +36,7 @@ identity information…). For example, the following state represents an IOU - an agreement that Alice owes Bob an amount X: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} Specifically, this state represents an IOU of £10 from Alice to Bob. As well as any information about the fact itself, the state also contains a reference to the *contract* that governs @@ -53,14 +53,14 @@ historic. This sequence of state replacements gives us a full view of the evolution of the shared fact over time. We can picture this situation as follows: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a *vault* - a database where it tracks all the current and historic states that it is aware of, and which it considers to be relevant to itself: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} We can think of the ledger from each node’s point of view as the set of all the current (i.e. non-historic) states that it is aware of. diff --git a/content/en/archived-docs/corda-os/4.6/key-concepts-tearoffs.md b/content/en/archived-docs/corda-os/4.6/key-concepts-tearoffs.md index 48039d58d70..c97c0d78392 100644 --- a/content/en/archived-docs/corda-os/4.6/key-concepts-tearoffs.md +++ b/content/en/archived-docs/corda-os/4.6/key-concepts-tearoffs.md @@ -58,7 +58,7 @@ reveal the content of low-entropy hashed values (i.e., a single-word text attach After computing the leaves, each Merkle tree is built in the normal way by hashing the concatenation of nodes’ hashes below the current one together. It’s visible on the example image below, where `H` denotes sha256 function, “+” - concatenation. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} The transaction has three input states, two output states, two commands, one attachment, a notary and a time-window. Notice that if a tree is not a full binary tree, leaves are padded to the nearest power of 2 with zero hash (since finding a pre-image of sha256(x) == 0 is hard computational task) - marked light @@ -77,7 +77,7 @@ Let’s assume that only the first command should be visible to an Oracle. We sh the commands requiring a signature from this oracle should be visible to the oracle entity, but not the rest. Here is how this filtered transaction will be represented in the Merkle tree structure. -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} Blue nodes and `H(c2)` are provided to the Oracle service, while the black ones are omitted. `H(c2)` is required, so that the Oracle can compute `H(commandData)` without being to able to see the second command, but at the same time ensuring `CommandData1` is part of the transaction. It is highlighted that all signers are visible, so as to have a @@ -93,4 +93,4 @@ apart from input states, time-window and the notary information. This data is en input states should be checked for double-spending, if the time-window is valid and if this transaction should be notarised by this notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/archived-docs/corda-os/4.6/key-concepts-time-windows.md b/content/en/archived-docs/corda-os/4.6/key-concepts-time-windows.md index 3d3fc9ee78c..a0191f4d9b4 100644 --- a/content/en/archived-docs/corda-os/4.6/key-concepts-time-windows.md +++ b/content/en/archived-docs/corda-os/4.6/key-concepts-time-windows.md @@ -53,7 +53,7 @@ For this reason, times in transactions are specified as time *windows*, not abso there can never be “true time”, only an approximation of it. Time windows can be open-ended (i.e. specify only one of “before” and “after”) or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} In this way, we express the idea that the *true value* of the fact “the current time” is actually unknowable. Even when both a before and an after time are included, the transaction could have occurred at any point within that time-window. diff --git a/content/en/archived-docs/corda-os/4.6/key-concepts-transactions.md b/content/en/archived-docs/corda-os/4.6/key-concepts-transactions.md index b69a6555591..72cc40df7d3 100644 --- a/content/en/archived-docs/corda-os/4.6/key-concepts-transactions.md +++ b/content/en/archived-docs/corda-os/4.6/key-concepts-transactions.md @@ -39,7 +39,7 @@ single link in the state sequences seen in [States](key-concepts-states.md). Here is an example of an update transaction, with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type: * They can include many different state types (states may represent cash or bonds, for example) @@ -66,7 +66,7 @@ These input states references are a combination of: This situation can be illustrated as follows: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} These input state references link transactions together over time, forming what is known as a *transaction chain*. ## Committing transactions @@ -74,14 +74,14 @@ These input state references link transactions together over time, forming what Initially, a transaction is just a **proposal** to update the ledger. It represents the future state of the ledger that is desired by the transaction builders: -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To become reality, the transaction must receive signatures from all of the *required signers* (see **Commands**, below). Each required signer appends their signature to the transaction to indicate that they approve the proposal: -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If all of the required signatures are gathered, the transaction becomes committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions @@ -128,7 +128,7 @@ This transaction comprises two commands: a settlement command which reduces the has two supporting attachments, and will only be notarised by NotaryClusterA if the notary pool receives it within the specified time-window. This transaction would look as follows: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -156,7 +156,7 @@ listed in the commands, we get the list of the transaction’s required signers. We can visualize this situation as follows: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/archived-docs/corda-os/4.6/key-concepts-vault.md b/content/en/archived-docs/corda-os/4.6/key-concepts-vault.md index 45153cd3974..169a941541b 100644 --- a/content/en/archived-docs/corda-os/4.6/key-concepts-vault.md +++ b/content/en/archived-docs/corda-os/4.6/key-concepts-vault.md @@ -65,7 +65,7 @@ The vault supports the management of data in both authoritative (“on-ledger” The following diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} Note the following: diff --git a/content/en/archived-docs/corda-os/4.6/network-builder.md b/content/en/archived-docs/corda-os/4.6/network-builder.md index e8055cdae64..195184281c4 100644 --- a/content/en/archived-docs/corda-os/4.6/network-builder.md +++ b/content/en/archived-docs/corda-os/4.6/network-builder.md @@ -21,7 +21,7 @@ title: Corda Network Builder The Corda Network Builder is a tool for building Corda networks for testing purposes. It leverages Docker and containers to abstract the complexity of managing a distributed network away from the user. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} The network you build will either be made up of local `Docker` nodes *or* of nodes spread across Azure containers. For each node a separate Docker image is built based on [corda/corda-zulu-java1.8-4.4](https://hub.docker.com/r/corda/corda-zulu-java1.8-4.4). diff --git a/content/en/archived-docs/corda-os/4.6/node-administration.md b/content/en/archived-docs/corda-os/4.6/node-administration.md index 4d785c9d809..a60c612399a 100644 --- a/content/en/archived-docs/corda-os/4.6/node-administration.md +++ b/content/en/archived-docs/corda-os/4.6/node-administration.md @@ -173,7 +173,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ## Memory usage and tuning diff --git a/content/en/archived-docs/corda-os/4.6/node-database-tables.md b/content/en/archived-docs/corda-os/4.6/node-database-tables.md index f7c118c8a16..f6f0d9520e0 100644 --- a/content/en/archived-docs/corda-os/4.6/node-database-tables.md +++ b/content/en/archived-docs/corda-os/4.6/node-database-tables.md @@ -49,7 +49,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more here: [The network map](network-map.md) -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -178,7 +178,7 @@ Read more in [The ledger](key-concepts-ledger.md) Read more in [Working with attachments](tutorial-attachments.md) and [Node services](node-services.md) -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -472,7 +472,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -501,7 +501,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/archived-docs/corda-os/4.6/node-explorer.md b/content/en/archived-docs/corda-os/4.6/node-explorer.md index 717dcff4c8f..0e4ad07f993 100644 --- a/content/en/archived-docs/corda-os/4.6/node-explorer.md +++ b/content/en/archived-docs/corda-os/4.6/node-explorer.md @@ -58,7 +58,7 @@ Run the installer on your machine in the way you would any other app. You can access any node with Node Explorer using the node's login credentials. If you are accessing a local node, or a remote node that is not protected with SSH, you can use the node's RPC login details. To access a remote node, protected by SSH, you also need the relevant port, username, and password. -{{< figure alt="login" width=80% zoom="resources/node-explorer/node-explorer-ssh-login.png" >}} +{{< figure alt="login" width=80% src="resources/node-explorer/node-explorer-ssh-login.png" >}} **To log in to a local or remote node without SSH credentials:** @@ -74,7 +74,7 @@ You can find this address by accessing your node through the command line - you {{< /note >}} -{{< figure alt="RPC connection address" width=80% zoom="resources/node-explorer/node-explorer-cl.png" >}} +{{< figure alt="RPC connection address" width=80% src="resources/node-explorer/node-explorer-cl.png" >}} 4. In the **Username** and **Password** fields, enter the username and password you would use to access your node. @@ -103,7 +103,7 @@ The Node Explorer dashboard is shown. If you are connecting to this node for the Before you can start using Node Explorer to execute flows, you need to add the directory of your CorDapps. This enables the explorer to discover the required parameters for each flow. -{{< figure alt="Settings" width=80% zoom="resources/node-explorer/node-explorer-settings.png" >}} +{{< figure alt="Settings" width=80% src="resources/node-explorer/node-explorer-settings.png" >}} To add your CorDapp directory: @@ -122,7 +122,7 @@ The dashboard is the first screen that opens when you [start Node Explorer](#acc On the dashboard, you can see two panels with details and diagnostics of two aspects of your node - **Node information** and **Network Parameters**. -{{< figure alt="Dashboard" width=80% zoom="resources/node-explorer/node-explorer-dash.png" >}} +{{< figure alt="Dashboard" width=80% src="resources/node-explorer/node-explorer-dash.png" >}} In the **Node information** panel you can see: @@ -149,7 +149,7 @@ The geographical location of each node is based on the }} +{{< figure alt="Map view" width=80% src="resources/node-explorer/node-explorer-map.png" >}} ## Execute transaction flows @@ -164,7 +164,7 @@ You can use Node Explorer to execute a range of commonly used flows, however not You can execute each flow by completing the required information in the UI, without any additional coding. Node Explorer identifies the required fields in your CorDapps, and presents them for you to complete. -{{< figure alt="Flows" width=80% zoom="resources/node-explorer/node-explorer-flow.png" >}} +{{< figure alt="Flows" width=80% src="resources/node-explorer/node-explorer-flow.png" >}} To execute a transaction flow: @@ -196,13 +196,13 @@ You have accessed the details of a transaction. You can see general details as w You can see the transaction organised by the inputs and outputs of the transaction state that exists as a result of an executed flow. There can be multiple inputs and outputs for each transaction - for example, when a loan has been issued and then partly repaid. -{{< figure alt="Transaction explorer" width=80% zoom="resources/node-explorer/node-explorer-transactions.png" >}} +{{< figure alt="Transaction explorer" width=80% src="resources/node-explorer/node-explorer-transactions.png" >}} ## Explore your node's vault The vault keeps the full transaction history of your node. You can use the dynamically populated filters to explore transactions of all types, for example transactions with a Contract state type of `CashState`. -{{< figure alt="Vault explorer" width=80% zoom="resources/node-explorer/node-explorer-vault.png" >}} +{{< figure alt="Vault explorer" width=80% src="resources/node-explorer/node-explorer-vault.png" >}} To access your node's vault: diff --git a/content/en/archived-docs/corda-os/4.6/permissioning.md b/content/en/archived-docs/corda-os/4.6/permissioning.md index b14d6d24881..23cd244622f 100644 --- a/content/en/archived-docs/corda-os/4.6/permissioning.md +++ b/content/en/archived-docs/corda-os/4.6/permissioning.md @@ -52,7 +52,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/archived-docs/corda-os/4.6/release-notes.md b/content/en/archived-docs/corda-os/4.6/release-notes.md index efd72952195..511eb3cd3d8 100644 --- a/content/en/archived-docs/corda-os/4.6/release-notes.md +++ b/content/en/archived-docs/corda-os/4.6/release-notes.md @@ -1072,7 +1072,7 @@ deployment and can also remotely control Microsoft Azure, to create a test netwo Learn more on the [Corda Network Builder](network-builder.md) page. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} #### JPA access in flows and services diff --git a/content/en/archived-docs/corda-os/4.6/tut-two-party-contract.md b/content/en/archived-docs/corda-os/4.6/tut-two-party-contract.md index 4c88f36a320..967a665973c 100644 --- a/content/en/archived-docs/corda-os/4.6/tut-two-party-contract.md +++ b/content/en/archived-docs/corda-os/4.6/tut-two-party-contract.md @@ -89,7 +89,7 @@ And finally, you'll want to impose constraints on who is required to sign the tr You can visualise this transaction as follows: -{{< figure alt="simple tutorial transaction 2" width=80% zoom="/en/images/simple-tutorial-transaction-2.png" >}} +{{< figure alt="simple tutorial transaction 2" width=80% src="/en/images/simple-tutorial-transaction-2.png" >}} ## Defining the IOUContract diff --git a/content/en/archived-docs/corda-os/4.6/tutorial-contract.md b/content/en/archived-docs/corda-os/4.6/tutorial-contract.md index bf2b75fddce..f450b64e182 100644 --- a/content/en/archived-docs/corda-os/4.6/tutorial-contract.md +++ b/content/en/archived-docs/corda-os/4.6/tutorial-contract.md @@ -43,7 +43,7 @@ value of the commercial paper. This lifecycle for commercial paper is illustrated in the diagram below: -{{< figure alt="contract cp" width=80% zoom="/en/images/contract-cp.png" >}} +{{< figure alt="contract cp" width=80% src="/en/images/contract-cp.png" >}} ## Defining the class @@ -90,7 +90,7 @@ piece of issued paper. A state is a class that stores data that is checked by the contract. A commercial paper state is structured as below: -{{< figure alt="contract cp state" width=80% zoom="/en/images/contract-cp-state.png" >}} +{{< figure alt="contract cp state" width=80% src="/en/images/contract-cp-state.png" >}} {{< tabs name="tabs-2" >}} {{% tab name="kotlin" %}} ```kotlin diff --git a/content/en/archived-docs/corda-os/4.6/upgrading-cordapps.md b/content/en/archived-docs/corda-os/4.6/upgrading-cordapps.md index 07f12994b3e..91781114ff0 100644 --- a/content/en/archived-docs/corda-os/4.6/upgrading-cordapps.md +++ b/content/en/archived-docs/corda-os/4.6/upgrading-cordapps.md @@ -74,7 +74,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="/en/images/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="/en/images/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/archived-docs/corda-os/4.7/api-core-types.md b/content/en/archived-docs/corda-os/4.7/api-core-types.md index 15b2dc8fd4b..078c7783a91 100644 --- a/content/en/archived-docs/corda-os/4.7/api-core-types.md +++ b/content/en/archived-docs/corda-os/4.7/api-core-types.md @@ -65,11 +65,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="/en/images/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="/en/images/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="/en/images/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="/en/images/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/archived-docs/corda-os/4.7/api-flows.md b/content/en/archived-docs/corda-os/4.7/api-flows.md index a656b05ea7a..59840ac0fac 100644 --- a/content/en/archived-docs/corda-os/4.7/api-flows.md +++ b/content/en/archived-docs/corda-os/4.7/api-flows.md @@ -72,7 +72,7 @@ In our flow, the Initiator flow class will be doing the majority of the work: We can visualize the work performed by initiator as follows: -{{< figure alt="flow overview" width=80% zoom="/en/images/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="/en/images/flow-overview.png" >}} ### Responder diff --git a/content/en/archived-docs/corda-os/4.7/api-states.md b/content/en/archived-docs/corda-os/4.7/api-states.md index 410b43db6eb..8c73e388962 100644 --- a/content/en/archived-docs/corda-os/4.7/api-states.md +++ b/content/en/archived-docs/corda-os/4.7/api-states.md @@ -96,7 +96,7 @@ the total amount held that is important, rather than the actual units held. We can picture the hierarchy as follows: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/archived-docs/corda-os/4.7/building-the-docs.md b/content/en/archived-docs/corda-os/4.7/building-the-docs.md index 5524b798916..d45574cc470 100644 --- a/content/en/archived-docs/corda-os/4.7/building-the-docs.md +++ b/content/en/archived-docs/corda-os/4.7/building-the-docs.md @@ -80,7 +80,7 @@ Or if you want to use Docker: As a result, there will be an extra icon in the title bar of your local docs site, which should open the current page in Visual Studio Code: -{{< figure alt="Visual Studio Code" width=80% zoom="/en/images/hugo-vscode-page-edit.png" >}} +{{< figure alt="Visual Studio Code" width=80% src="/en/images/hugo-vscode-page-edit.png" >}} ## Edit web pages directly in Atom diff --git a/content/en/archived-docs/corda-os/4.7/cheat-sheet.md b/content/en/archived-docs/corda-os/4.7/cheat-sheet.md index be752d5c975..bf7300adc71 100644 --- a/content/en/archived-docs/corda-os/4.7/cheat-sheet.md +++ b/content/en/archived-docs/corda-os/4.7/cheat-sheet.md @@ -16,5 +16,5 @@ title: Cheat sheet A “cheat sheet” summarizing the key Corda types. A PDF version is downloadable [here](/en/pdf/corda-cheat-sheet.pdf). -{{< figure alt="cheatsheet" width=80% zoom="/en/images/cheatsheet.jpg" >}} +{{< figure alt="cheatsheet" width=80% src="/en/images/cheatsheet.jpg" >}} diff --git a/content/en/archived-docs/corda-os/4.7/cipher-suites.md b/content/en/archived-docs/corda-os/4.7/cipher-suites.md index c9f6dee8301..36a096cf8e2 100644 --- a/content/en/archived-docs/corda-os/4.7/cipher-suites.md +++ b/content/en/archived-docs/corda-os/4.7/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates](permissioning.md)): -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/archived-docs/corda-os/4.7/contract-irs.md b/content/en/archived-docs/corda-os/4.7/contract-irs.md index 33e3765cd1f..6403134beef 100644 --- a/content/en/archived-docs/corda-os/4.7/contract-irs.md +++ b/content/en/archived-docs/corda-os/4.7/contract-irs.md @@ -48,7 +48,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="/en/images/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="/en/images/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/archived-docs/corda-os/4.7/cordapp-advanced-concepts.md b/content/en/archived-docs/corda-os/4.7/cordapp-advanced-concepts.md index b0d40520ee0..c7ff754d9c5 100644 --- a/content/en/archived-docs/corda-os/4.7/cordapp-advanced-concepts.md +++ b/content/en/archived-docs/corda-os/4.7/cordapp-advanced-concepts.md @@ -73,7 +73,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/archived-docs/corda-os/4.7/cordapp-overview.md b/content/en/archived-docs/corda-os/4.7/cordapp-overview.md index b62b41a963c..dde89af5b91 100644 --- a/content/en/archived-docs/corda-os/4.7/cordapp-overview.md +++ b/content/en/archived-docs/corda-os/4.7/cordapp-overview.md @@ -22,7 +22,7 @@ CorDapps (Corda Distributed Applications) are distributed applications that run CorDapp is to allow nodes to reach agreement on updates to the ledger. They achieve this goal by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="/en/images/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="/en/images/node-diagram.png" >}} ## CorDapp components diff --git a/content/en/archived-docs/corda-os/4.7/financial-model.md b/content/en/archived-docs/corda-os/4.7/financial-model.md index c58c4117d37..8a397af420e 100644 --- a/content/en/archived-docs/corda-os/4.7/financial-model.md +++ b/content/en/archived-docs/corda-os/4.7/financial-model.md @@ -93,6 +93,6 @@ countable (in cents), barrels of West Texas crude are fungible and countable (oi container), shares of the same class in a specific company are fungible and countable, and so on. The following diagram illustrates the complete Contract State hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Note there are currently two packages, a core library and a finance model specific library. Developers may re-use or extend the Finance types directly or write their own by extending the base types from the Core library. diff --git a/content/en/archived-docs/corda-os/4.7/hello-world-flow.md b/content/en/archived-docs/corda-os/4.7/hello-world-flow.md index 0688ed549ed..708662ce25c 100644 --- a/content/en/archived-docs/corda-os/4.7/hello-world-flow.md +++ b/content/en/archived-docs/corda-os/4.7/hello-world-flow.md @@ -241,7 +241,7 @@ You’ll build your transaction proposal in two steps: Our transaction will have the following structure: -{{< figure alt="simple tutorial transaction" width=80% zoom="/en/images/simple-tutorial-transaction.png" >}} +{{< figure alt="simple tutorial transaction" width=80% src="/en/images/simple-tutorial-transaction.png" >}} * The output `IOUState` on the right represents the state you will be adding to the ledger. As you can see, there are diff --git a/content/en/archived-docs/corda-os/4.7/hello-world-introduction.md b/content/en/archived-docs/corda-os/4.7/hello-world-introduction.md index 65f6f25d7d0..81fe542b1ea 100644 --- a/content/en/archived-docs/corda-os/4.7/hello-world-introduction.md +++ b/content/en/archived-docs/corda-os/4.7/hello-world-introduction.md @@ -67,7 +67,7 @@ For a state, you will use the `IOUState`, representing an IOU. It will contain t `IOUState` as follows: -{{< figure alt="tutorial state" width=80% zoom="/en/images/tutorial-state.png" >}} +{{< figure alt="tutorial state" width=80% src="/en/images/tutorial-state.png" >}} ### IOUFlow @@ -76,7 +76,7 @@ For a flow, you will use the `IOUFlow`. This flow will completely automate the p steps: -{{< figure alt="simple tutorial flow" width=80% zoom="/en/images/simple-tutorial-flow.png" >}} +{{< figure alt="simple tutorial flow" width=80% src="/en/images/simple-tutorial-flow.png" >}} ### IOUContract diff --git a/content/en/archived-docs/corda-os/4.7/hello-world-running.md b/content/en/archived-docs/corda-os/4.7/hello-world-running.md index 84cb25aa660..3fff03eb792 100644 --- a/content/en/archived-docs/corda-os/4.7/hello-world-running.md +++ b/content/en/archived-docs/corda-os/4.7/hello-world-running.md @@ -115,7 +115,7 @@ This will start a terminal window for each node. Give each node a moment to star the message “Welcome to the Corda interactive shell.”. -{{< figure alt="running node" width=80% zoom="/en/images/running_node.png" >}} +{{< figure alt="running node" width=80% src="/en/images/running_node.png" >}} ## Interacting with the nodes diff --git a/content/en/archived-docs/corda-os/4.7/key-concepts-consensus.md b/content/en/archived-docs/corda-os/4.7/key-concepts-consensus.md index b992b57ed87..696539cbd0e 100644 --- a/content/en/archived-docs/corda-os/4.7/key-concepts-consensus.md +++ b/content/en/archived-docs/corda-os/4.7/key-concepts-consensus.md @@ -53,7 +53,7 @@ transferring us a treasury bond. We can only be sure that the bond transfer is v The only way to be sure of both conditions is to walk the transaction’s chain. We can visualize this process as follows: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a given party may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer(s). The transaction proposer(s) will always have the full transaction chain, since they would have requested it when @@ -70,7 +70,7 @@ proposals: This is a problem because, although both transactions will achieve validity consensus, Bob has managed to “double-spend” his USD to get double the amount of GBP and EUR. We can visualize this as follows: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/archived-docs/corda-os/4.7/key-concepts-contracts.md b/content/en/archived-docs/corda-os/4.7/key-concepts-contracts.md index 718965bf046..2609e2e0c70 100644 --- a/content/en/archived-docs/corda-os/4.7/key-concepts-contracts.md +++ b/content/en/archived-docs/corda-os/4.7/key-concepts-contracts.md @@ -47,7 +47,7 @@ valid We can picture this situation as follows: -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code has access to the full capabilities of the language, including: diff --git a/content/en/archived-docs/corda-os/4.7/key-concepts-djvm.md b/content/en/archived-docs/corda-os/4.7/key-concepts-djvm.md index 5b109060999..7cce9132454 100644 --- a/content/en/archived-docs/corda-os/4.7/key-concepts-djvm.md +++ b/content/en/archived-docs/corda-os/4.7/key-concepts-djvm.md @@ -76,7 +76,7 @@ severity `ERROR` will prevent execution. The sandbox has a configuration that applies to the execution of a specific runnable. This configuration, on a higher level, contains a set of rules, definition providers and emitters. -{{< figure alt="djvm overview" width=80% zoom="/en/images/djvm-overview.png" >}} +{{< figure alt="djvm overview" width=80% src="/en/images/djvm-overview.png" >}} The set of rules is what defines the constraints posed on the runtime environment. A rule can act on three different levels, namely on a type-, member- or instruction-level. The set of rules get processed and validated by the `RuleValidator` prior to execution. diff --git a/content/en/archived-docs/corda-os/4.7/key-concepts-ecosystem.md b/content/en/archived-docs/corda-os/4.7/key-concepts-ecosystem.md index 34c94e08596..e4503d1e52c 100644 --- a/content/en/archived-docs/corda-os/4.7/key-concepts-ecosystem.md +++ b/content/en/archived-docs/corda-os/4.7/key-concepts-ecosystem.md @@ -29,7 +29,7 @@ title: Network A Corda network is a peer-to-peer network of **nodes**. Each node represents a legal entity, and each runs the Corda software (an instance of Corda and one or more Corda applications, known as **CorDapps**). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} All communication between nodes is point-to-point and encrypted using transport-layer security. This means that data is shared only on a need-to-know basis. There are **no global broadcasts**. diff --git a/content/en/archived-docs/corda-os/4.7/key-concepts-flows.md b/content/en/archived-docs/corda-os/4.7/key-concepts-flows.md index 89fbf02a00a..76bb1b74554 100644 --- a/content/en/archived-docs/corda-os/4.7/key-concepts-flows.md +++ b/content/en/archived-docs/corda-os/4.7/key-concepts-flows.md @@ -36,7 +36,7 @@ what order. Here is a visualisation of the process of agreeing a simple ledger update between Alice and Bob: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -45,7 +45,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is the sequence of flow steps involved in the simple ledger update above: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/archived-docs/corda-os/4.7/key-concepts-ledger.md b/content/en/archived-docs/corda-os/4.7/key-concepts-ledger.md index 1fd17d18a13..74d1fb29a64 100644 --- a/content/en/archived-docs/corda-os/4.7/key-concepts-ledger.md +++ b/content/en/archived-docs/corda-os/4.7/key-concepts-ledger.md @@ -37,7 +37,7 @@ The facts that a node knows about are those that it is involved with. For exampl Example: A network with five nodes, where each numbered circle on an intersection represents a fact shared between two or more nodes. -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} The preceding Venn diagram represents 5 nodes (Alice, Bob, Carl, Demi and Ed) as sets. Where the sets overlap are shared facts, such as those known by both Alice and Bob (1 and 7). Notably, in this Venn diagram, Alice only shares facts with Bob. Alice does not share facts with any of Carl, Demi or Ed. @@ -61,7 +61,7 @@ In the previous diagram, we could see that although Carl, Demi and Ed are aware You can think of this vault as being a database or simple table. -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} Where the rows are shared between nodes (facts 1 and 7 in this example), these are shared facts. Corda guarantees that whenever one of these facts is shared by multiple nodes on the network, it evolves in lockstep in the database of every node that is aware of it. This means that Alice and Bob will both see an **exactly identical version** of shared facts 1 and 7. diff --git a/content/en/archived-docs/corda-os/4.7/key-concepts-node.md b/content/en/archived-docs/corda-os/4.7/key-concepts-node.md index ffc89e6f71a..7bf49d19cee 100644 --- a/content/en/archived-docs/corda-os/4.7/key-concepts-node.md +++ b/content/en/archived-docs/corda-os/4.7/key-concepts-node.md @@ -37,7 +37,7 @@ CorDapps. We can visualize the node’s internal architecture as follows: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: * A persistence layer for storing data diff --git a/content/en/archived-docs/corda-os/4.7/key-concepts-states.md b/content/en/archived-docs/corda-os/4.7/key-concepts-states.md index 8ac2d3afad7..d98a8dccb32 100644 --- a/content/en/archived-docs/corda-os/4.7/key-concepts-states.md +++ b/content/en/archived-docs/corda-os/4.7/key-concepts-states.md @@ -36,7 +36,7 @@ identity information…). For example, the following state represents an IOU - an agreement that Alice owes Bob an amount X: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} Specifically, this state represents an IOU of £10 from Alice to Bob. As well as any information about the fact itself, the state also contains a reference to the *contract* that governs @@ -53,14 +53,14 @@ historic. This sequence of state replacements gives us a full view of the evolution of the shared fact over time. We can picture this situation as follows: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a *vault* - a database where it tracks all the current and historic states that it is aware of, and which it considers to be relevant to itself: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} We can think of the ledger from each node’s point of view as the set of all the current (i.e. non-historic) states that it is aware of. diff --git a/content/en/archived-docs/corda-os/4.7/key-concepts-tearoffs.md b/content/en/archived-docs/corda-os/4.7/key-concepts-tearoffs.md index fc6923ab383..e9afd0e3158 100644 --- a/content/en/archived-docs/corda-os/4.7/key-concepts-tearoffs.md +++ b/content/en/archived-docs/corda-os/4.7/key-concepts-tearoffs.md @@ -58,7 +58,7 @@ reveal the content of low-entropy hashed values (i.e., a single-word text attach After computing the leaves, each Merkle tree is built in the normal way by hashing the concatenation of nodes’ hashes below the current one together. It’s visible on the example image below, where `H` denotes sha256 function, “+” - concatenation. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} The transaction has three input states, two output states, two commands, one attachment, a notary and a time-window. Notice that if a tree is not a full binary tree, leaves are padded to the nearest power of 2 with zero hash (since finding a pre-image of sha256(x) == 0 is hard computational task) - marked light @@ -77,7 +77,7 @@ Let’s assume that only the first command should be visible to an Oracle. We sh the commands requiring a signature from this oracle should be visible to the oracle entity, but not the rest. Here is how this filtered transaction will be represented in the Merkle tree structure. -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} Blue nodes and `H(c2)` are provided to the Oracle service, while the black ones are omitted. `H(c2)` is required, so that the Oracle can compute `H(commandData)` without being to able to see the second command, but at the same time ensuring `CommandData1` is part of the transaction. It is highlighted that all signers are visible, so as to have a @@ -93,4 +93,4 @@ apart from input states, time-window and the notary information. This data is en input states should be checked for double-spending, if the time-window is valid and if this transaction should be notarised by this notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/archived-docs/corda-os/4.7/key-concepts-time-windows.md b/content/en/archived-docs/corda-os/4.7/key-concepts-time-windows.md index 2299e9ddd7b..66034ccde4f 100644 --- a/content/en/archived-docs/corda-os/4.7/key-concepts-time-windows.md +++ b/content/en/archived-docs/corda-os/4.7/key-concepts-time-windows.md @@ -53,7 +53,7 @@ For this reason, times in transactions are specified as time *windows*, not abso there can never be “true time”, only an approximation of it. Time windows can be open-ended (i.e. specify only one of “before” and “after”) or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} In this way, we express the idea that the *true value* of the fact “the current time” is actually unknowable. Even when both a before and an after time are included, the transaction could have occurred at any point within that time-window. diff --git a/content/en/archived-docs/corda-os/4.7/key-concepts-transactions.md b/content/en/archived-docs/corda-os/4.7/key-concepts-transactions.md index 6c76356f9ff..95ee5090a2f 100644 --- a/content/en/archived-docs/corda-os/4.7/key-concepts-transactions.md +++ b/content/en/archived-docs/corda-os/4.7/key-concepts-transactions.md @@ -39,7 +39,7 @@ single link in the state sequences seen in [States](key-concepts-states.md). Here is an example of an update transaction, with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type: * They can include many different state types (states may represent cash or bonds, for example) @@ -66,7 +66,7 @@ These input states references are a combination of: This situation can be illustrated as follows: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} These input state references link transactions together over time, forming what is known as a *transaction chain*. {{< note >}} @@ -78,14 +78,14 @@ See [Reissuing states](reissuing-states.md) for information about reissuing stat Initially, a transaction is just a **proposal** to update the ledger. It represents the future state of the ledger that is desired by the transaction builders: -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To become reality, the transaction must receive signatures from all of the *required signers* (see **Commands**, below). Each required signer appends their signature to the transaction to indicate that they approve the proposal: -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If all of the required signatures are gathered, the transaction becomes committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions @@ -132,7 +132,7 @@ This transaction comprises two commands: a settlement command which reduces the has two supporting attachments, and will only be notarised by NotaryClusterA if the notary pool receives it within the specified time-window. This transaction would look as follows: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -160,7 +160,7 @@ listed in the commands, we get the list of the transaction’s required signers. We can visualize this situation as follows: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/archived-docs/corda-os/4.7/key-concepts-vault.md b/content/en/archived-docs/corda-os/4.7/key-concepts-vault.md index faa3f7ba02e..bcff610a198 100644 --- a/content/en/archived-docs/corda-os/4.7/key-concepts-vault.md +++ b/content/en/archived-docs/corda-os/4.7/key-concepts-vault.md @@ -65,7 +65,7 @@ The vault supports the management of data in both authoritative (“on-ledger” The following diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} Note the following: diff --git a/content/en/archived-docs/corda-os/4.7/network-builder.md b/content/en/archived-docs/corda-os/4.7/network-builder.md index ca3826d1712..4d10e652444 100644 --- a/content/en/archived-docs/corda-os/4.7/network-builder.md +++ b/content/en/archived-docs/corda-os/4.7/network-builder.md @@ -21,7 +21,7 @@ title: Corda Network Builder The Corda Network Builder is a tool for building Corda networks for testing purposes. It leverages Docker and containers to abstract the complexity of managing a distributed network away from the user. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} The network you build will either be made up of local `Docker` nodes *or* of nodes spread across Azure containers. For each node a separate Docker image is built based on [corda/corda-zulu-java1.8-4.4](https://hub.docker.com/r/corda/corda-zulu-java1.8-4.4). diff --git a/content/en/archived-docs/corda-os/4.7/node-administration.md b/content/en/archived-docs/corda-os/4.7/node-administration.md index 3fae02d4db6..624429474d2 100644 --- a/content/en/archived-docs/corda-os/4.7/node-administration.md +++ b/content/en/archived-docs/corda-os/4.7/node-administration.md @@ -173,7 +173,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ## Memory usage and tuning diff --git a/content/en/archived-docs/corda-os/4.7/node-database-tables.md b/content/en/archived-docs/corda-os/4.7/node-database-tables.md index 14784b9f66a..4d8a2c94a11 100644 --- a/content/en/archived-docs/corda-os/4.7/node-database-tables.md +++ b/content/en/archived-docs/corda-os/4.7/node-database-tables.md @@ -49,7 +49,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more here: [The network map](network-map.md) -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -178,7 +178,7 @@ Read more in [The ledger](key-concepts-ledger.md) Read more in [Working with attachments](tutorial-attachments.md) and [Node services](node-services.md) -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -472,7 +472,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -501,7 +501,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/archived-docs/corda-os/4.7/node-explorer.md b/content/en/archived-docs/corda-os/4.7/node-explorer.md index ed62d904ad5..4e217f7f02a 100644 --- a/content/en/archived-docs/corda-os/4.7/node-explorer.md +++ b/content/en/archived-docs/corda-os/4.7/node-explorer.md @@ -58,7 +58,7 @@ Run the installer on your machine in the way you would any other app. You can access any node with Node Explorer using the node's login credentials. If you are accessing a local node, or a remote node that is not protected with SSH, you can use the node's RPC login details. To access a remote node, protected by SSH, you also need the relevant port, username, and password. -{{< figure alt="login" width=80% zoom="resources/node-explorer/node-explorer-ssh-login.png" >}} +{{< figure alt="login" width=80% src="resources/node-explorer/node-explorer-ssh-login.png" >}} **To log in to a local or remote node without SSH credentials:** @@ -74,7 +74,7 @@ You can find this address by accessing your node through the command line - you {{< /note >}} -{{< figure alt="RPC connection address" width=80% zoom="resources/node-explorer/node-explorer-cl.png" >}} +{{< figure alt="RPC connection address" width=80% src="resources/node-explorer/node-explorer-cl.png" >}} 4. In the **Username** and **Password** fields, enter the username and password you would use to access your node. @@ -103,7 +103,7 @@ The Node Explorer dashboard is shown. If you are connecting to this node for the Before you can start using Node Explorer to execute flows, you need to add the directory of your CorDapps. This enables the explorer to discover the required parameters for each flow. -{{< figure alt="Settings" width=80% zoom="resources/node-explorer/node-explorer-settings.png" >}} +{{< figure alt="Settings" width=80% src="resources/node-explorer/node-explorer-settings.png" >}} To add your CorDapp directory: @@ -122,7 +122,7 @@ The dashboard is the first screen that opens when you [start Node Explorer](#acc On the dashboard, you can see two panels with details and diagnostics of two aspects of your node - **Node information** and **Network Parameters**. -{{< figure alt="Dashboard" width=80% zoom="resources/node-explorer/node-explorer-dash.png" >}} +{{< figure alt="Dashboard" width=80% src="resources/node-explorer/node-explorer-dash.png" >}} In the **Node information** panel you can see: @@ -149,7 +149,7 @@ The geographical location of each node is based on the [`locality` property of t On the network screen, you can see your Node's location, and the location of peers on your network. -{{< figure alt="Map view" width=80% zoom="resources/node-explorer/node-explorer-map.png" >}} +{{< figure alt="Map view" width=80% src="resources/node-explorer/node-explorer-map.png" >}} ## Execute transaction flows @@ -164,7 +164,7 @@ You can use Node Explorer to execute a range of commonly used flows, however not You can execute each flow by completing the required information in the UI, without any additional coding. Node Explorer identifies the required fields in your CorDapps, and presents them for you to complete. -{{< figure alt="Flows" width=80% zoom="resources/node-explorer/node-explorer-flow.png" >}} +{{< figure alt="Flows" width=80% src="resources/node-explorer/node-explorer-flow.png" >}} To execute a transaction flow: @@ -196,13 +196,13 @@ You have accessed the details of a transaction. You can see general details as w You can see the transaction organised by the inputs and outputs of the transaction state that exists as a result of an executed flow. There can be multiple inputs and outputs for each transaction - for example, when a loan has been issued and then partly repaid. -{{< figure alt="Transaction explorer" width=80% zoom="resources/node-explorer/node-explorer-transactions.png" >}} +{{< figure alt="Transaction explorer" width=80% src="resources/node-explorer/node-explorer-transactions.png" >}} ## Explore your node's vault The vault keeps the full transaction history of your node. You can use the dynamically populated filters to explore transactions of all types, for example transactions with a Contract state type of `CashState`. -{{< figure alt="Vault explorer" width=80% zoom="resources/node-explorer/node-explorer-vault.png" >}} +{{< figure alt="Vault explorer" width=80% src="resources/node-explorer/node-explorer-vault.png" >}} To access your node's vault: diff --git a/content/en/archived-docs/corda-os/4.7/permissioning.md b/content/en/archived-docs/corda-os/4.7/permissioning.md index bf46af202b8..9e613629739 100644 --- a/content/en/archived-docs/corda-os/4.7/permissioning.md +++ b/content/en/archived-docs/corda-os/4.7/permissioning.md @@ -52,7 +52,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/archived-docs/corda-os/4.7/release-notes.md b/content/en/archived-docs/corda-os/4.7/release-notes.md index 895328642be..e12cffce27c 100644 --- a/content/en/archived-docs/corda-os/4.7/release-notes.md +++ b/content/en/archived-docs/corda-os/4.7/release-notes.md @@ -1153,7 +1153,7 @@ deployment and can also remotely control Microsoft Azure, to create a test netwo Learn more on the [Corda Network Builder](network-builder.md) page. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} #### JPA access in flows and services diff --git a/content/en/archived-docs/corda-os/4.7/tut-two-party-contract.md b/content/en/archived-docs/corda-os/4.7/tut-two-party-contract.md index 776d17d7162..4c18042a31e 100644 --- a/content/en/archived-docs/corda-os/4.7/tut-two-party-contract.md +++ b/content/en/archived-docs/corda-os/4.7/tut-two-party-contract.md @@ -91,7 +91,7 @@ And finally, you'll want to impose constraints on who is required to sign the tr You can visualise this transaction as follows: -{{< figure alt="simple tutorial transaction 2" width=80% zoom="/en/images/simple-tutorial-transaction-2.png" >}} +{{< figure alt="simple tutorial transaction 2" width=80% src="/en/images/simple-tutorial-transaction-2.png" >}} ## Defining the IOUContract diff --git a/content/en/archived-docs/corda-os/4.7/tutorial-contract.md b/content/en/archived-docs/corda-os/4.7/tutorial-contract.md index 4ed4fdae1af..95d76b4de03 100644 --- a/content/en/archived-docs/corda-os/4.7/tutorial-contract.md +++ b/content/en/archived-docs/corda-os/4.7/tutorial-contract.md @@ -43,7 +43,7 @@ value of the commercial paper. This lifecycle for commercial paper is illustrated in the diagram below: -{{< figure alt="contract cp" width=80% zoom="/en/images/contract-cp.png" >}} +{{< figure alt="contract cp" width=80% src="/en/images/contract-cp.png" >}} {{< note >}} See [Reissuing states](reissuing-states.md) for information about reissuing states with a guaranteed state replacement, which allows you to break transaction backchains. @@ -93,7 +93,7 @@ piece of issued paper. A state is a class that stores data that is checked by the contract. A commercial paper state is structured as below: -{{< figure alt="contract cp state" width=80% zoom="/en/images/contract-cp-state.png" >}} +{{< figure alt="contract cp state" width=80% src="/en/images/contract-cp-state.png" >}} {{< tabs name="tabs-2" >}} {{% tab name="kotlin" %}} ```kotlin diff --git a/content/en/archived-docs/corda-os/4.7/upgrading-cordapps.md b/content/en/archived-docs/corda-os/4.7/upgrading-cordapps.md index d74095be9ee..d869174a02e 100644 --- a/content/en/archived-docs/corda-os/4.7/upgrading-cordapps.md +++ b/content/en/archived-docs/corda-os/4.7/upgrading-cordapps.md @@ -74,7 +74,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="/en/images/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="/en/images/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/archived-docs/corda-os/4.8/api-core-types.md b/content/en/archived-docs/corda-os/4.8/api-core-types.md index fdd556c9e04..307aa57eafb 100644 --- a/content/en/archived-docs/corda-os/4.8/api-core-types.md +++ b/content/en/archived-docs/corda-os/4.8/api-core-types.md @@ -67,11 +67,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="./resources/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="./resources/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="./resources/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="./resources/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/archived-docs/corda-os/4.8/api-flows.md b/content/en/archived-docs/corda-os/4.8/api-flows.md index a596e4dc156..ad9773cd693 100644 --- a/content/en/archived-docs/corda-os/4.8/api-flows.md +++ b/content/en/archived-docs/corda-os/4.8/api-flows.md @@ -91,7 +91,7 @@ The `initiator`: You can visualize the work performed by initiator like this: -{{< figure alt="flow overview" width=80% zoom="./resources/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="./resources/flow-overview.png" >}} ## Responder flow class example diff --git a/content/en/archived-docs/corda-os/4.8/api-states.md b/content/en/archived-docs/corda-os/4.8/api-states.md index 44726354d66..034605a815f 100644 --- a/content/en/archived-docs/corda-os/4.8/api-states.md +++ b/content/en/archived-docs/corda-os/4.8/api-states.md @@ -68,7 +68,7 @@ common sub-interfaces are `LinearState` and `OwnableState`. You can visualize the hierarchy like this: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/archived-docs/corda-os/4.8/building-the-docs.md b/content/en/archived-docs/corda-os/4.8/building-the-docs.md index 682b941e8c8..2f76b6e1963 100644 --- a/content/en/archived-docs/corda-os/4.8/building-the-docs.md +++ b/content/en/archived-docs/corda-os/4.8/building-the-docs.md @@ -80,7 +80,7 @@ Or if you want to use Docker: As a result, there will be an extra icon in the title bar of your local docs site, which should open the current page in Visual Studio Code: -{{< figure alt="Visual Studio Code" width=80% zoom="/en/images/hugo-vscode-page-edit.png" >}} +{{< figure alt="Visual Studio Code" width=80% src="/en/images/hugo-vscode-page-edit.png" >}} ## Edit web pages directly in Atom diff --git a/content/en/archived-docs/corda-os/4.8/cheat-sheet.md b/content/en/archived-docs/corda-os/4.8/cheat-sheet.md index be752d5c975..bf7300adc71 100644 --- a/content/en/archived-docs/corda-os/4.8/cheat-sheet.md +++ b/content/en/archived-docs/corda-os/4.8/cheat-sheet.md @@ -16,5 +16,5 @@ title: Cheat sheet A “cheat sheet” summarizing the key Corda types. A PDF version is downloadable [here](/en/pdf/corda-cheat-sheet.pdf). -{{< figure alt="cheatsheet" width=80% zoom="/en/images/cheatsheet.jpg" >}} +{{< figure alt="cheatsheet" width=80% src="/en/images/cheatsheet.jpg" >}} diff --git a/content/en/archived-docs/corda-os/4.8/cipher-suites.md b/content/en/archived-docs/corda-os/4.8/cipher-suites.md index 7b48ef487f5..1587c4d179c 100644 --- a/content/en/archived-docs/corda-os/4.8/cipher-suites.md +++ b/content/en/archived-docs/corda-os/4.8/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates](permissioning.md)): -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/archived-docs/corda-os/4.8/contract-irs.md b/content/en/archived-docs/corda-os/4.8/contract-irs.md index afb0a831d89..1812766544c 100644 --- a/content/en/archived-docs/corda-os/4.8/contract-irs.md +++ b/content/en/archived-docs/corda-os/4.8/contract-irs.md @@ -48,7 +48,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="/en/images/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="/en/images/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/archived-docs/corda-os/4.8/cordapp-advanced-concepts.md b/content/en/archived-docs/corda-os/4.8/cordapp-advanced-concepts.md index a8feb59572a..471b161038a 100644 --- a/content/en/archived-docs/corda-os/4.8/cordapp-advanced-concepts.md +++ b/content/en/archived-docs/corda-os/4.8/cordapp-advanced-concepts.md @@ -73,7 +73,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/archived-docs/corda-os/4.8/cordapp-overview.md b/content/en/archived-docs/corda-os/4.8/cordapp-overview.md index d67c8266ad3..925c34d6db1 100644 --- a/content/en/archived-docs/corda-os/4.8/cordapp-overview.md +++ b/content/en/archived-docs/corda-os/4.8/cordapp-overview.md @@ -22,7 +22,7 @@ CorDapps (Corda Distributed Applications) are distributed applications that run CorDapp is to allow nodes to reach agreement on updates to the ledger. They achieve this goal by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="/en/images/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="/en/images/node-diagram.png" >}} ## CorDapp components diff --git a/content/en/archived-docs/corda-os/4.8/financial-model.md b/content/en/archived-docs/corda-os/4.8/financial-model.md index 9edc1ac8f60..931974cea26 100644 --- a/content/en/archived-docs/corda-os/4.8/financial-model.md +++ b/content/en/archived-docs/corda-os/4.8/financial-model.md @@ -93,6 +93,6 @@ countable (in cents), barrels of West Texas crude are fungible and countable (oi container), shares of the same class in a specific company are fungible and countable, and so on. The following diagram illustrates the complete Contract State hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Note there are currently two packages, a core library and a finance model specific library. Developers may re-use or extend the Finance types directly or write their own by extending the base types from the Core library. diff --git a/content/en/archived-docs/corda-os/4.8/key-concepts-consensus.md b/content/en/archived-docs/corda-os/4.8/key-concepts-consensus.md index dfcc340214d..bd4defa1454 100644 --- a/content/en/archived-docs/corda-os/4.8/key-concepts-consensus.md +++ b/content/en/archived-docs/corda-os/4.8/key-concepts-consensus.md @@ -49,7 +49,7 @@ transferring a treasury bond, the bond transfer is only valid if: Walking the chain for this transaction would look like this: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a node may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer. The @@ -68,7 +68,7 @@ proposals: Both transactions will achieve validity consensus, yet Alice has managed to “double-spend” her USD to get double the amount of GBP and EUR: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/archived-docs/corda-os/4.8/key-concepts-contracts.md b/content/en/archived-docs/corda-os/4.8/key-concepts-contracts.md index 2ab59cd53bc..a4c51c3901e 100644 --- a/content/en/archived-docs/corda-os/4.8/key-concepts-contracts.md +++ b/content/en/archived-docs/corda-os/4.8/key-concepts-contracts.md @@ -55,7 +55,7 @@ transaction gathers all the required signatures, it can't be executed unless it Each transaction [state](key-concepts-states.md) specifies a *contract type*. The contract specified takes the transaction as input, and determines if the transaction is valid based on the contract's internal rules. The contract must evaluate every input state and every output state. -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code can: * Check the number of inputs, outputs, commands, or attachments. diff --git a/content/en/archived-docs/corda-os/4.8/key-concepts-djvm.md b/content/en/archived-docs/corda-os/4.8/key-concepts-djvm.md index a88ba880205..1a43312c1e0 100644 --- a/content/en/archived-docs/corda-os/4.8/key-concepts-djvm.md +++ b/content/en/archived-docs/corda-os/4.8/key-concepts-djvm.md @@ -76,7 +76,7 @@ severity `ERROR` will prevent execution. The sandbox has a configuration that applies to the execution of a specific runnable. This configuration, on a higher level, contains a set of rules, definition providers and emitters. -{{< figure alt="djvm overview" width=80% zoom="/en/images/djvm-overview.png" >}} +{{< figure alt="djvm overview" width=80% src="/en/images/djvm-overview.png" >}} The set of rules is what defines the constraints posed on the runtime environment. A rule can act on three different levels, namely on a type-, member- or instruction-level. The set of rules get processed and validated by the `RuleValidator` prior to execution. diff --git a/content/en/archived-docs/corda-os/4.8/key-concepts-ecosystem.md b/content/en/archived-docs/corda-os/4.8/key-concepts-ecosystem.md index 4460d714eed..c958f1102c7 100644 --- a/content/en/archived-docs/corda-os/4.8/key-concepts-ecosystem.md +++ b/content/en/archived-docs/corda-os/4.8/key-concepts-ecosystem.md @@ -32,7 +32,7 @@ title: Networks, identity, and discovery ## What is a network? On Corda, people and business interact by communicating over a peer-to-peer network of [Corda nodes](key-concepts-node.md). Each node represents a legal entity running Corda and one or more Corda distributed applications, known as [CorDapps](cordapp-overview.md). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} Corda is different from other distributed ledgers because all communication between nodes is point-to-point, and only shared on a need-to-know basis. It's also encrypted using transport-layer security. There are *no global broadcasts* to all parties on a network, but all of the nodes in a network can send messages directly to other nodes. If the recipient is offline, the message waits in an outbound queue until they are online again—just like an email. ## Join a network diff --git a/content/en/archived-docs/corda-os/4.8/key-concepts-flows.md b/content/en/archived-docs/corda-os/4.8/key-concepts-flows.md index 20bc9c2ea75..69225c408eb 100644 --- a/content/en/archived-docs/corda-os/4.8/key-concepts-flows.md +++ b/content/en/archived-docs/corda-os/4.8/key-concepts-flows.md @@ -35,7 +35,7 @@ must specify what information needs to be sent, to which counterparties, and in Here is a visualisation of Alice and Bob agreeing a ledger update using this process: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -44,7 +44,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is a diagram showing the flow's steps used between Alice and Bob to perform the ledger update: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/archived-docs/corda-os/4.8/key-concepts-ledger.md b/content/en/archived-docs/corda-os/4.8/key-concepts-ledger.md index cd8defd89bf..d6785822f41 100644 --- a/content/en/archived-docs/corda-os/4.8/key-concepts-ledger.md +++ b/content/en/archived-docs/corda-os/4.8/key-concepts-ledger.md @@ -39,7 +39,7 @@ loan are Alice and Bob, then they are the only nodes that ever see or store this This diagram shows a network with five nodes (Alice, Bob, Carl, Demi, and Ed). Each numbered circle on an intersection represents a fact shared between two or more nodes: -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} In the diagram, facts 1 and 7 are known by both Alice and Bob. Alice only shares facts with Bob, Alice doesn't share any facts with Carl, Demi, or Ed. @@ -56,7 +56,7 @@ each node maintains its own vault, which contains all of its known facts. You can think of a vault as being a database or simple table. In this diagram, facts 1 and 7 appear on both Alice's vault and Bob's vault, and are therefore shared facts: -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} When multiple nodes on a network share an evolving fact, the changes to the fact update at the same time in each node's vault. This means that Alice and Bob will both see an *identical version* of shared facts 1 and 7. diff --git a/content/en/archived-docs/corda-os/4.8/key-concepts-node.md b/content/en/archived-docs/corda-os/4.8/key-concepts-node.md index f6dd12a21a0..a9d5de8bb3e 100644 --- a/content/en/archived-docs/corda-os/4.8/key-concepts-node.md +++ b/content/en/archived-docs/corda-os/4.8/key-concepts-node.md @@ -35,7 +35,7 @@ title: Nodes A Corda node runs within a Java Virtual Machine (JVM) runtime environment with a [unique network identity](../../../../../en/platform/corda/4.8/open-source/key-concepts-ecosystem.html#node-identities). JVM runtime environments provide a consistent platform on which you can run and deploy Java applications, such as Corda services and CorDapps. Here is a visualization of the node’s internal architecture: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: diff --git a/content/en/archived-docs/corda-os/4.8/key-concepts-states.md b/content/en/archived-docs/corda-os/4.8/key-concepts-states.md index 8e5b7a80ec7..f3060b918b3 100644 --- a/content/en/archived-docs/corda-os/4.8/key-concepts-states.md +++ b/content/en/archived-docs/corda-os/4.8/key-concepts-states.md @@ -35,7 +35,7 @@ You can use states to represent any type of data, and any kind of fact. For exam This state represents an IOU—an agreement that Alice owes Bob £10: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} In addition to information about the fact, the state contains a reference to the **[contract](key-concepts-contracts.md)**. Contracts govern the evolution of states. @@ -47,14 +47,14 @@ When a fact changes, one of the state's participants creates a new state and mar For example, if Alice pays Bob £5, the state sequence would be: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a **vault**. This is the node's database used to store current and historic states where the node is a participant. For example: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} From each node's point of view, the ledger is the current (non-historic) states where that node is a participant. diff --git a/content/en/archived-docs/corda-os/4.8/key-concepts-tearoffs.md b/content/en/archived-docs/corda-os/4.8/key-concepts-tearoffs.md index 6f762d8089a..1bb859ad489 100644 --- a/content/en/archived-docs/corda-os/4.8/key-concepts-tearoffs.md +++ b/content/en/archived-docs/corda-os/4.8/key-concepts-tearoffs.md @@ -39,7 +39,7 @@ Merkle trees split transactions into "leaves". Each leaf contains either an input, an output, a command, or an attachment. The final nested tree structure also contains the other fields of the transaction, such as the time window, the notary, and the required signers. The only component type that requires two trees instead of one is the command, which is split into command data and required signers for visibility purposes. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} Corda uses one nested Merkle tree per component type. A component sub-tree is generated for each component type (for example, inputs, outputs, or attachments). The roots of these sub-trees @@ -65,7 +65,7 @@ obtained belongs to that particular transaction. In this example, assume that only the first command should be visible to the oracle. You must provide guarantees that all the commands the oracle needs to sign are visible to the oracle entity, but no other data. The transaction would be represented in the Merkle tree structure like this: -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} The blue nodes and `H(c2)` are provided to the oracle service, while the black ones are omitted. The oracle needs `H(c2)` so it can compute `H(commandData)` without being to able to see the second command. At the same time, this ensures that `CommandData1` is part of the transaction. All signers are visible as @@ -79,4 +79,4 @@ To send the same transaction to a non-validating notary, hide all components apart from input states, time window, and the notary information. This data is enough for the notary to know which input states to check for double-spending, if the time-window is valid, and if the transaction is being notarized by the correct notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/archived-docs/corda-os/4.8/key-concepts-time-windows.md b/content/en/archived-docs/corda-os/4.8/key-concepts-time-windows.md index 88254a287e6..353801fd591 100644 --- a/content/en/archived-docs/corda-os/4.8/key-concepts-time-windows.md +++ b/content/en/archived-docs/corda-os/4.8/key-concepts-time-windows.md @@ -46,7 +46,7 @@ trade, or requesting human sign-off. Times in transactions are specified as time *windows*, not absolute times. Time windows can be open-ended, and specify only “before” **or** “after”, or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} When both a before and an after time are included the transaction occurred at some point within that time window. diff --git a/content/en/archived-docs/corda-os/4.8/key-concepts-transactions.md b/content/en/archived-docs/corda-os/4.8/key-concepts-transactions.md index 0ae0df54be3..3a62dca6e4c 100644 --- a/content/en/archived-docs/corda-os/4.8/key-concepts-transactions.md +++ b/content/en/archived-docs/corda-os/4.8/key-concepts-transactions.md @@ -37,7 +37,7 @@ Every [state](key-concepts-states.md) is *immutable*—it can't be changed. This Here is an example of a transaction with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type. Transactions can: * Include different types of states representing multiple financial instruments, such as cash or bonds. @@ -65,21 +65,21 @@ Input state references consist of: You can see how this works in this example transaction: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} ## Committing transactions to the ledger Initially, a transaction is only a proposal to update the ledger. It represents the future state of the ledger desired by the transaction builders. -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To be committed to the ledger, the transaction must receive signatures from all the *required signers*. Each required signer appends their signature to the transaction to approve the proposal. -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If the transaction gathers the required signatures, it is committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions. @@ -121,7 +121,7 @@ For example, suppose Alice uses $5 cash to pay off $5 of an IOU with Bob. This transaction contains a *settlement command* which reduces the amount outstanding on the IOU, and a *payment command* which changes the ownership of $5 from Alice to Bob. It also has two supporting attachments, and is notarized by `NotaryClusterA` if the notary pool receives it within the specified time window: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -145,7 +145,7 @@ listed in the commands, you get the list of the transaction’s required signers This situation would look like this: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/archived-docs/corda-os/4.8/key-concepts-vault.md b/content/en/archived-docs/corda-os/4.8/key-concepts-vault.md index dc259be43cb..c4633e4f970 100644 --- a/content/en/archived-docs/corda-os/4.8/key-concepts-vault.md +++ b/content/en/archived-docs/corda-os/4.8/key-concepts-vault.md @@ -45,7 +45,7 @@ The vault supports the management of data in both authoritative **on-ledger** fo This diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} You can see: diff --git a/content/en/archived-docs/corda-os/4.8/network-builder.md b/content/en/archived-docs/corda-os/4.8/network-builder.md index fe868cbb9c0..810dbb04922 100644 --- a/content/en/archived-docs/corda-os/4.8/network-builder.md +++ b/content/en/archived-docs/corda-os/4.8/network-builder.md @@ -21,7 +21,7 @@ title: Corda Network Builder The Corda Network Builder is a tool for building Corda networks for testing purposes. It leverages Docker and containers to abstract the complexity of managing a distributed network away from the user. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} The network you build will either be made up of local `Docker` nodes *or* of nodes spread across Azure containers. For each node a separate Docker image is built based on [corda/corda-zulu-java1.8-4.4](https://hub.docker.com/r/corda/corda-zulu-java1.8-4.4). diff --git a/content/en/archived-docs/corda-os/4.8/node-administration.md b/content/en/archived-docs/corda-os/4.8/node-administration.md index aa5a6376aa6..2e090dcd4a0 100644 --- a/content/en/archived-docs/corda-os/4.8/node-administration.md +++ b/content/en/archived-docs/corda-os/4.8/node-administration.md @@ -173,7 +173,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ## Memory usage and tuning diff --git a/content/en/archived-docs/corda-os/4.8/node-database-tables.md b/content/en/archived-docs/corda-os/4.8/node-database-tables.md index 8bf296e36b3..33a527864c3 100644 --- a/content/en/archived-docs/corda-os/4.8/node-database-tables.md +++ b/content/en/archived-docs/corda-os/4.8/node-database-tables.md @@ -49,7 +49,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more here: [The network map](network-map.md) -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -178,7 +178,7 @@ Read more in [the ledger](key-concepts-ledger.md) Read more in [Working with attachments]({{< relref "../../../../tutorials/corda/4.8/os/supplementary-tutorials/tutorial-attachments.md" >}}) and [Node services](node-services.md) -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -469,7 +469,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -498,7 +498,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/archived-docs/corda-os/4.8/node-explorer.md b/content/en/archived-docs/corda-os/4.8/node-explorer.md index daebffcffc5..597fbe55a9d 100644 --- a/content/en/archived-docs/corda-os/4.8/node-explorer.md +++ b/content/en/archived-docs/corda-os/4.8/node-explorer.md @@ -58,7 +58,7 @@ Run the installer on your machine in the way you would any other app. You can access any node with Node Explorer using the node's login credentials. If you are accessing a local node, or a remote node that is not protected with SSH, you can use the node's RPC login details. To access a remote node, protected by SSH, you also need the relevant port, username, and password. -{{< figure alt="login" width=80% zoom="resources/node-explorer/node-explorer-ssh-login.png" >}} +{{< figure alt="login" width=80% src="resources/node-explorer/node-explorer-ssh-login.png" >}} **To log in to a local or remote node without SSH credentials:** @@ -74,7 +74,7 @@ You can find this address by accessing your node through the command line - you {{< /note >}} -{{< figure alt="RPC connection address" width=80% zoom="resources/node-explorer/node-explorer-cl.png" >}} +{{< figure alt="RPC connection address" width=80% src="resources/node-explorer/node-explorer-cl.png" >}} 4. In the **Username** and **Password** fields, enter the username and password you would use to access your node. @@ -103,7 +103,7 @@ The Node Explorer dashboard is shown. If you are connecting to this node for the Before you can start using Node Explorer to execute flows, you need to add the directory of your CorDapps. This enables the explorer to discover the required parameters for each flow. -{{< figure alt="Settings" width=80% zoom="resources/node-explorer/node-explorer-settings.png" >}} +{{< figure alt="Settings" width=80% src="resources/node-explorer/node-explorer-settings.png" >}} To add your CorDapp directory: @@ -122,7 +122,7 @@ The dashboard is the first screen that opens when you [start Node Explorer](#acc On the dashboard, you can see two panels with details and diagnostics of two aspects of your node - **Node information** and **Network Parameters**. -{{< figure alt="Dashboard" width=80% zoom="resources/node-explorer/node-explorer-dash.png" >}} +{{< figure alt="Dashboard" width=80% src="resources/node-explorer/node-explorer-dash.png" >}} In the **Node information** panel you can see: @@ -149,7 +149,7 @@ The geographical location of each node is based on the [`locality` property of t On the network screen, you can see your Node's location, and the location of peers on your network. -{{< figure alt="Map view" width=80% zoom="resources/node-explorer/node-explorer-map.png" >}} +{{< figure alt="Map view" width=80% src="resources/node-explorer/node-explorer-map.png" >}} ## Execute transaction flows @@ -164,7 +164,7 @@ You can use Node Explorer to execute a range of commonly used flows, however not You can execute each flow by completing the required information in the UI, without any additional coding. Node Explorer identifies the required fields in your CorDapps, and presents them for you to complete. -{{< figure alt="Flows" width=80% zoom="resources/node-explorer/node-explorer-flow.png" >}} +{{< figure alt="Flows" width=80% src="resources/node-explorer/node-explorer-flow.png" >}} To execute a transaction flow: @@ -196,13 +196,13 @@ You have accessed the details of a transaction. You can see general details as w You can see the transaction organised by the inputs and outputs of the transaction state that exists as a result of an executed flow. There can be multiple inputs and outputs for each transaction - for example, when a loan has been issued and then partly repaid. -{{< figure alt="Transaction explorer" width=80% zoom="resources/node-explorer/node-explorer-transactions.png" >}} +{{< figure alt="Transaction explorer" width=80% src="resources/node-explorer/node-explorer-transactions.png" >}} ## Explore your node's vault The vault keeps the full transaction history of your node. You can use the dynamically populated filters to explore transactions of all types, for example transactions with a Contract state type of `CashState`. -{{< figure alt="Vault explorer" width=80% zoom="resources/node-explorer/node-explorer-vault.png" >}} +{{< figure alt="Vault explorer" width=80% src="resources/node-explorer/node-explorer-vault.png" >}} To access your node's vault: diff --git a/content/en/archived-docs/corda-os/4.8/permissioning.md b/content/en/archived-docs/corda-os/4.8/permissioning.md index d98bb7926a2..c2bb7726248 100644 --- a/content/en/archived-docs/corda-os/4.8/permissioning.md +++ b/content/en/archived-docs/corda-os/4.8/permissioning.md @@ -52,7 +52,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/archived-docs/corda-os/4.8/upgrading-cordapps.md b/content/en/archived-docs/corda-os/4.8/upgrading-cordapps.md index 3e1ad712ab1..369079c9453 100644 --- a/content/en/archived-docs/corda-os/4.8/upgrading-cordapps.md +++ b/content/en/archived-docs/corda-os/4.8/upgrading-cordapps.md @@ -74,7 +74,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="/en/images/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="/en/images/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/archived-docs/corda-os/4.9/api-core-types.md b/content/en/archived-docs/corda-os/4.9/api-core-types.md index 73e40b3845d..505b0625ab5 100644 --- a/content/en/archived-docs/corda-os/4.9/api-core-types.md +++ b/content/en/archived-docs/corda-os/4.9/api-core-types.md @@ -67,11 +67,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="./resources/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="./resources/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="./resources/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="./resources/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/archived-docs/corda-os/4.9/api-flows.md b/content/en/archived-docs/corda-os/4.9/api-flows.md index 20bc2374f8f..1cc5eb8548f 100644 --- a/content/en/archived-docs/corda-os/4.9/api-flows.md +++ b/content/en/archived-docs/corda-os/4.9/api-flows.md @@ -91,7 +91,7 @@ The `initiator`: You can visualize the work performed by initiator like this: -{{< figure alt="flow overview" width=80% zoom="./resources/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="./resources/flow-overview.png" >}} ## Responder flow class example diff --git a/content/en/archived-docs/corda-os/4.9/api-states.md b/content/en/archived-docs/corda-os/4.9/api-states.md index 682a3fe1cc3..aba3d7f6e15 100644 --- a/content/en/archived-docs/corda-os/4.9/api-states.md +++ b/content/en/archived-docs/corda-os/4.9/api-states.md @@ -68,7 +68,7 @@ common sub-interfaces are `LinearState` and `OwnableState`. You can visualize the hierarchy like this: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/archived-docs/corda-os/4.9/apps/bankinabox/user-interface/how-to.md b/content/en/archived-docs/corda-os/4.9/apps/bankinabox/user-interface/how-to.md index f8b9e25b36a..b991949b9a6 100644 --- a/content/en/archived-docs/corda-os/4.9/apps/bankinabox/user-interface/how-to.md +++ b/content/en/archived-docs/corda-os/4.9/apps/bankinabox/user-interface/how-to.md @@ -70,7 +70,7 @@ Follow these steps to create a new customer profile. When the customer profile is created, they will not have any accounts - you will have to create them. Learn how under [Creating accounts](#create-a-current-account). {{< /note >}} -{{< figure alt="Create customer profile" width=80% zoom="/en/gifs/create-customer-biab-1.0.gif" >}} +{{< figure alt="Create customer profile" width=80% src="/en/gifs/create-customer-biab-1.0.gif" >}} ### Create a Current account @@ -94,7 +94,7 @@ When the customer profile is created, they will not have any accounts - you will 7. When an account is created, it is in **PENDING** status. This must be changed to **ACTIVE** for a customer to be able to interact with and use the account. See [Change an account status](#change-an-account-status) for more information. -{{< figure alt="Create account" width=80% zoom="/en/gifs/create-current-account-biab-1.0.gif" >}} +{{< figure alt="Create account" width=80% src="/en/gifs/create-current-account-biab-1.0.gif" >}} ### Create a Savings account @@ -140,7 +140,7 @@ An account has three statuses: **PENDING**, **ACTIVE**, and **SUSPENDED**. When If the account needs to be suspended, follow the same steps but select **SUSPENDED**. -{{< figure alt="Set account status" width=80% zoom="/en/gifs/set-account-status-biab-1.0.gif" >}} +{{< figure alt="Set account status" width=80% src="/en/gifs/set-account-status-biab-1.0.gif" >}} ### Assign or revoke a user role @@ -163,7 +163,7 @@ To assign a user role, follow these steps: 5. Click **Revoke**. A message will appear indicating that the user role was assigned successfully. -{{< figure alt="Assign role" width=80% zoom="/en/gifs/assign-a-role-biab-1.0.gif" >}} +{{< figure alt="Assign role" width=80% src="/en/gifs/assign-a-role-biab-1.0.gif" >}} #### Revoke a user role @@ -179,7 +179,7 @@ To revoke a user role, follow these steps: 5. Click **Save**. A message will appear indicating that the user role was revoked successfully. -{{< figure alt="Revoke role" width=80% zoom="/en/gifs/revoke-role-biab-1.0.gif" >}} +{{< figure alt="Revoke role" width=80% src="/en/gifs/revoke-role-biab-1.0.gif" >}} ### Issue a loan @@ -195,7 +195,7 @@ Once the account has been set to **ACTIVE**, you will have the ability to issue A loan account is created when a loan has been issued successfully. -{{< figure alt="Issue loan" width=80% zoom="/en/gifs/issue-loan-biab-1.0.gif" >}} +{{< figure alt="Issue loan" width=80% src="/en/gifs/issue-loan-biab-1.0.gif" >}} ### Approve overdrafts @@ -215,7 +215,7 @@ To approve an overdraft, follow these steps. Overdrafts can be approved whether the account is **PENDING**, **ACTIVE**, or **SUSPENDED**. {{< /note >}} -{{< figure alt="Approve overdraft" width=80% zoom="/en/gifs/approve-overdraft-biab-1.0.gif" >}} +{{< figure alt="Approve overdraft" width=80% src="/en/gifs/approve-overdraft-biab-1.0.gif" >}} ### Deposit money to an account @@ -230,7 +230,7 @@ Follow these steps to deposit money to a customer account. 4. Click **Save**. You will receive a message indicating that the deposit was successful. -{{< figure alt="Deposit" width=80% zoom="/en/gifs/deposit-biab-1.0.gif" >}} +{{< figure alt="Deposit" width=80% src="/en/gifs/deposit-biab-1.0.gif" >}} ### Register as a user on Bank in a Box @@ -251,7 +251,7 @@ You must be registered as a **Customer** or **Admin** on Bank in a Box to perfor 5. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update customer profile @@ -284,7 +284,7 @@ An **Admin user** can set an account's **Withdrawal daily limit** or **Transfer 2. Click **Save** when you've entered the desired limits. A message will appear indicating that the limits have been saved successfully. -{{< figure alt="Set withdrawal and transfer limits - admin" width=80% zoom="/en/gifs/set-limits-admin-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - admin" width=80% src="/en/gifs/set-limits-admin-biab-1.0.gif" >}} ## Customer tasks @@ -309,12 +309,12 @@ Follow these steps to create a new intrabank payment. 6. Click **Save**. You will receive a notification indicating that the payment was created successfully. You will also receive notifications indicating any changes in your account balances. -{{< figure alt="Create intrabank payment" width=80% zoom="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} +{{< figure alt="Create intrabank payment" width=80% src="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} After making a payment, you can view the details of this transaction on the Transactions screen. -{{< figure alt="View transaction" width="800" width=80% zoom="/en/gifs/view-transaction-biab-1.0.gif" >}} +{{< figure alt="View transaction" width="800" width=80% src="/en/gifs/view-transaction-biab-1.0.gif" >}} ### Create a recurring payment @@ -338,7 +338,7 @@ Follow these steps to create a recurring payment: 3. You will be taken back to the **Recurring payments screen** where you will receive a message indicating that the recurring payment was created successfully. -{{< figure alt="Recurring payment" width=80% zoom="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} +{{< figure alt="Recurring payment" width=80% src="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} {{< note >}} This payment will not appear on the **Recurring payments screen** until the first iteration has occurred. @@ -367,7 +367,7 @@ You must be registered as a Customer or Admin on Bank in a Box to perform tasks. 7. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update a customer profile @@ -406,4 +406,4 @@ To set these limits as a **Customer**, follow these steps. 4. Click **Save**. You will be taken back to the Account page where you will receive a message indicating that the limits have been updated successfully. -{{< figure alt="Set withdrawal and transfer limits - customer" width=80% zoom="/en/gifs/set-limits-customer-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - customer" width=80% src="/en/gifs/set-limits-customer-biab-1.0.gif" >}} diff --git a/content/en/archived-docs/corda-os/4.9/building-the-docs.md b/content/en/archived-docs/corda-os/4.9/building-the-docs.md index 3dc8cd756fa..d054404765e 100644 --- a/content/en/archived-docs/corda-os/4.9/building-the-docs.md +++ b/content/en/archived-docs/corda-os/4.9/building-the-docs.md @@ -78,7 +78,7 @@ Or if you want to use Docker: As a result, there will be an extra icon in the title bar of your local docs site, which should open the current page in Visual Studio Code: -{{< figure alt="Visual Studio Code" width=80% zoom="/en/images/hugo-vscode-page-edit.png" >}} +{{< figure alt="Visual Studio Code" width=80% src="/en/images/hugo-vscode-page-edit.png" >}} ## Edit web pages directly in Atom diff --git a/content/en/archived-docs/corda-os/4.9/cheat-sheet.md b/content/en/archived-docs/corda-os/4.9/cheat-sheet.md index be752d5c975..bf7300adc71 100644 --- a/content/en/archived-docs/corda-os/4.9/cheat-sheet.md +++ b/content/en/archived-docs/corda-os/4.9/cheat-sheet.md @@ -16,5 +16,5 @@ title: Cheat sheet A “cheat sheet” summarizing the key Corda types. A PDF version is downloadable [here](/en/pdf/corda-cheat-sheet.pdf). -{{< figure alt="cheatsheet" width=80% zoom="/en/images/cheatsheet.jpg" >}} +{{< figure alt="cheatsheet" width=80% src="/en/images/cheatsheet.jpg" >}} diff --git a/content/en/archived-docs/corda-os/4.9/cipher-suites.md b/content/en/archived-docs/corda-os/4.9/cipher-suites.md index c8232708e78..f67b854e71d 100644 --- a/content/en/archived-docs/corda-os/4.9/cipher-suites.md +++ b/content/en/archived-docs/corda-os/4.9/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates](permissioning.md)): -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/archived-docs/corda-os/4.9/contract-irs.md b/content/en/archived-docs/corda-os/4.9/contract-irs.md index 7cd08776893..428b1501e59 100644 --- a/content/en/archived-docs/corda-os/4.9/contract-irs.md +++ b/content/en/archived-docs/corda-os/4.9/contract-irs.md @@ -48,7 +48,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="/en/images/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="/en/images/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/archived-docs/corda-os/4.9/cordapp-advanced-concepts.md b/content/en/archived-docs/corda-os/4.9/cordapp-advanced-concepts.md index 52401200e71..8f26f596fe9 100644 --- a/content/en/archived-docs/corda-os/4.9/cordapp-advanced-concepts.md +++ b/content/en/archived-docs/corda-os/4.9/cordapp-advanced-concepts.md @@ -73,7 +73,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/archived-docs/corda-os/4.9/cordapp-overview.md b/content/en/archived-docs/corda-os/4.9/cordapp-overview.md index c2ff7efeb24..6cfe3419352 100644 --- a/content/en/archived-docs/corda-os/4.9/cordapp-overview.md +++ b/content/en/archived-docs/corda-os/4.9/cordapp-overview.md @@ -22,7 +22,7 @@ CorDapps (Corda Distributed Applications) are distributed applications that run CorDapp is to allow nodes to reach agreement on updates to the ledger. They achieve this goal by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="/en/images/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="/en/images/node-diagram.png" >}} ## CorDapp components diff --git a/content/en/archived-docs/corda-os/4.9/financial-model.md b/content/en/archived-docs/corda-os/4.9/financial-model.md index 467b30fa485..2e90b36bf65 100644 --- a/content/en/archived-docs/corda-os/4.9/financial-model.md +++ b/content/en/archived-docs/corda-os/4.9/financial-model.md @@ -93,6 +93,6 @@ countable (in cents), barrels of West Texas crude are fungible and countable (oi container), shares of the same class in a specific company are fungible and countable, and so on. The following diagram illustrates the complete Contract State hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Note there are currently two packages, a core library and a finance model specific library. Developers may re-use or extend the Finance types directly or write their own by extending the base types from the Core library. diff --git a/content/en/archived-docs/corda-os/4.9/key-concepts-consensus.md b/content/en/archived-docs/corda-os/4.9/key-concepts-consensus.md index e369ec4009e..a76a0d62734 100644 --- a/content/en/archived-docs/corda-os/4.9/key-concepts-consensus.md +++ b/content/en/archived-docs/corda-os/4.9/key-concepts-consensus.md @@ -49,7 +49,7 @@ transferring a treasury bond, the bond transfer is only valid if: Walking the chain for this transaction would look like this: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a node may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer. The @@ -68,7 +68,7 @@ proposals: Both transactions will achieve validity consensus, yet Alice has managed to “double-spend” her USD to get double the amount of GBP and EUR: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/archived-docs/corda-os/4.9/key-concepts-contracts.md b/content/en/archived-docs/corda-os/4.9/key-concepts-contracts.md index 70a9578b31f..d41f848b19a 100644 --- a/content/en/archived-docs/corda-os/4.9/key-concepts-contracts.md +++ b/content/en/archived-docs/corda-os/4.9/key-concepts-contracts.md @@ -55,7 +55,7 @@ transaction gathers all the required signatures, it can't be executed unless it Each transaction [state](key-concepts-states.md) specifies a *contract type*. The contract specified takes the transaction as input, and determines if the transaction is valid based on the contract's internal rules. The contract must evaluate every input state and every output state. -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code can: * Check the number of inputs, outputs, commands, or attachments. diff --git a/content/en/archived-docs/corda-os/4.9/key-concepts-djvm.md b/content/en/archived-docs/corda-os/4.9/key-concepts-djvm.md index a0b0b5fda07..deaa05f32a9 100644 --- a/content/en/archived-docs/corda-os/4.9/key-concepts-djvm.md +++ b/content/en/archived-docs/corda-os/4.9/key-concepts-djvm.md @@ -76,7 +76,7 @@ severity `ERROR` will prevent execution. The sandbox has a configuration that applies to the execution of a specific runnable. This configuration, on a higher level, contains a set of rules, definition providers and emitters. -{{< figure alt="djvm overview" width=80% zoom="/en/images/djvm-overview.png" >}} +{{< figure alt="djvm overview" width=80% src="/en/images/djvm-overview.png" >}} The set of rules is what defines the constraints posed on the runtime environment. A rule can act on three different levels, namely on a type-, member- or instruction-level. The set of rules get processed and validated by the `RuleValidator` prior to execution. diff --git a/content/en/archived-docs/corda-os/4.9/key-concepts-ecosystem.md b/content/en/archived-docs/corda-os/4.9/key-concepts-ecosystem.md index ae00bd7e576..d1cf6dadca9 100644 --- a/content/en/archived-docs/corda-os/4.9/key-concepts-ecosystem.md +++ b/content/en/archived-docs/corda-os/4.9/key-concepts-ecosystem.md @@ -32,7 +32,7 @@ title: Networks, identity, and discovery ## What is a network? On Corda, people and business interact by communicating over a peer-to-peer network of [Corda nodes](key-concepts-node.md). Each node represents a legal entity running Corda and one or more Corda distributed applications, known as [CorDapps](cordapp-overview.md). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} Corda is different from other distributed ledgers because all communication between nodes is point-to-point, and only shared on a need-to-know basis. It's also encrypted using transport-layer security. There are *no global broadcasts* to all parties on a network, but all of the nodes in a network can send messages directly to other nodes. If the recipient is offline, the message waits in an outbound queue until they are online again—just like an email. ## Join a network diff --git a/content/en/archived-docs/corda-os/4.9/key-concepts-flows.md b/content/en/archived-docs/corda-os/4.9/key-concepts-flows.md index fc348a86436..2b726efff01 100644 --- a/content/en/archived-docs/corda-os/4.9/key-concepts-flows.md +++ b/content/en/archived-docs/corda-os/4.9/key-concepts-flows.md @@ -35,7 +35,7 @@ must specify what information needs to be sent, to which counterparties, and in Here is a visualisation of Alice and Bob agreeing a ledger update using this process: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -44,7 +44,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is a diagram showing the flow's steps used between Alice and Bob to perform the ledger update: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/archived-docs/corda-os/4.9/key-concepts-ledger.md b/content/en/archived-docs/corda-os/4.9/key-concepts-ledger.md index a0745459e76..53e49a8a0c7 100644 --- a/content/en/archived-docs/corda-os/4.9/key-concepts-ledger.md +++ b/content/en/archived-docs/corda-os/4.9/key-concepts-ledger.md @@ -39,7 +39,7 @@ loan are Alice and Bob, then they are the only nodes that ever see or store this This diagram shows a network with five nodes (Alice, Bob, Carl, Demi, and Ed). Each numbered circle on an intersection represents a fact shared between two or more nodes: -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} In the diagram, facts 1 and 7 are known by both Alice and Bob. Alice only shares facts with Bob, Alice doesn't share any facts with Carl, Demi, or Ed. @@ -56,7 +56,7 @@ each node maintains its own vault, which contains all of its known facts. You can think of a vault as being a database or simple table. In this diagram, facts 1 and 7 appear on both Alice's vault and Bob's vault, and are therefore shared facts: -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} When multiple nodes on a network share an evolving fact, the changes to the fact update at the same time in each node's vault. This means that Alice and Bob will both see an *identical version* of shared facts 1 and 7. diff --git a/content/en/archived-docs/corda-os/4.9/key-concepts-node.md b/content/en/archived-docs/corda-os/4.9/key-concepts-node.md index 1827a6a75a6..384efac9839 100644 --- a/content/en/archived-docs/corda-os/4.9/key-concepts-node.md +++ b/content/en/archived-docs/corda-os/4.9/key-concepts-node.md @@ -35,7 +35,7 @@ title: Nodes A Corda node runs within a Java Virtual Machine (JVM) runtime environment with a [unique network identity](key-concepts-ecosystem.html#node-identities). JVM runtime environments provide a consistent platform on which you can run and deploy Java applications, such as Corda services and CorDapps. Here is a visualization of the node’s internal architecture: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: diff --git a/content/en/archived-docs/corda-os/4.9/key-concepts-states.md b/content/en/archived-docs/corda-os/4.9/key-concepts-states.md index eeddbbd4946..ba48b9591b8 100644 --- a/content/en/archived-docs/corda-os/4.9/key-concepts-states.md +++ b/content/en/archived-docs/corda-os/4.9/key-concepts-states.md @@ -35,7 +35,7 @@ You can use states to represent any type of data, and any kind of fact. For exam This state represents an IOU—an agreement that Alice owes Bob £10: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} In addition to information about the fact, the state contains a reference to the **[contract](key-concepts-contracts.md)**. Contracts govern the evolution of states. @@ -47,14 +47,14 @@ When a fact changes, one of the state's participants creates a new state and mar For example, if Alice pays Bob £5, the state sequence would be: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a **vault**. This is the node's database used to store current and historic states where the node is a participant. For example: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} From each node's point of view, the ledger is the current (non-historic) states where that node is a participant. diff --git a/content/en/archived-docs/corda-os/4.9/key-concepts-tearoffs.md b/content/en/archived-docs/corda-os/4.9/key-concepts-tearoffs.md index 862a8792922..490b4114b8c 100644 --- a/content/en/archived-docs/corda-os/4.9/key-concepts-tearoffs.md +++ b/content/en/archived-docs/corda-os/4.9/key-concepts-tearoffs.md @@ -39,7 +39,7 @@ Merkle trees split transactions into "leaves". Each leaf contains either an input, an output, a command, or an attachment. The final nested tree structure also contains the other fields of the transaction, such as the time window, the notary, and the required signers. The only component type that requires two trees instead of one is the command, which is split into command data and required signers for visibility purposes. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} Corda uses one nested Merkle tree per component type. A component sub-tree is generated for each component type (for example, inputs, outputs, or attachments). The roots of these sub-trees @@ -65,7 +65,7 @@ obtained belongs to that particular transaction. In this example, assume that only the first command should be visible to the oracle. You must provide guarantees that all the commands the oracle needs to sign are visible to the oracle entity, but no other data. The transaction would be represented in the Merkle tree structure like this: -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} The blue nodes and `H(c2)` are provided to the oracle service, while the black ones are omitted. The oracle needs `H(c2)` so it can compute `H(commandData)` without being to able to see the second command. At the same time, this ensures that `CommandData1` is part of the transaction. All signers are visible as @@ -79,4 +79,4 @@ To send the same transaction to a non-validating notary, hide all components apart from input states, time window, and the notary information. This data is enough for the notary to know which input states to check for double-spending, if the time-window is valid, and if the transaction is being notarized by the correct notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/archived-docs/corda-os/4.9/key-concepts-time-windows.md b/content/en/archived-docs/corda-os/4.9/key-concepts-time-windows.md index 483b997f028..3d7019343d1 100644 --- a/content/en/archived-docs/corda-os/4.9/key-concepts-time-windows.md +++ b/content/en/archived-docs/corda-os/4.9/key-concepts-time-windows.md @@ -46,7 +46,7 @@ trade, or requesting human sign-off. Times in transactions are specified as time *windows*, not absolute times. Time windows can be open-ended, and specify only “before” **or** “after”, or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} When both a before and an after time are included the transaction occurred at some point within that time window. diff --git a/content/en/archived-docs/corda-os/4.9/key-concepts-transactions.md b/content/en/archived-docs/corda-os/4.9/key-concepts-transactions.md index 89c19599dc4..8eea4961bf4 100644 --- a/content/en/archived-docs/corda-os/4.9/key-concepts-transactions.md +++ b/content/en/archived-docs/corda-os/4.9/key-concepts-transactions.md @@ -37,7 +37,7 @@ Every [state](key-concepts-states.md) is *immutable*—it can't be changed. This Here is an example of a transaction with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type. Transactions can: * Include different types of states representing multiple financial instruments, such as cash or bonds. @@ -65,21 +65,21 @@ Input state references consist of: You can see how this works in this example transaction: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} ## Committing transactions to the ledger Initially, a transaction is only a proposal to update the ledger. It represents the future state of the ledger desired by the transaction builders. -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To be committed to the ledger, the transaction must receive signatures from all the *required signers*. Each required signer appends their signature to the transaction to approve the proposal. -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If the transaction gathers the required signatures, it is committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions. @@ -121,7 +121,7 @@ For example, suppose Alice uses $5 cash to pay off $5 of an IOU with Bob. This transaction contains a *settlement command* which reduces the amount outstanding on the IOU, and a *payment command* which changes the ownership of $5 from Alice to Bob. It also has two supporting attachments, and is notarized by `NotaryClusterA` if the notary pool receives it within the specified time window: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -145,7 +145,7 @@ listed in the commands, you get the list of the transaction’s required signers This situation would look like this: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/archived-docs/corda-os/4.9/key-concepts-vault.md b/content/en/archived-docs/corda-os/4.9/key-concepts-vault.md index 47d8ff95b9d..cb46038ad6b 100644 --- a/content/en/archived-docs/corda-os/4.9/key-concepts-vault.md +++ b/content/en/archived-docs/corda-os/4.9/key-concepts-vault.md @@ -47,7 +47,7 @@ The vault supports the management of data in both authoritative **on-ledger** fo This diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} You can see: diff --git a/content/en/archived-docs/corda-os/4.9/network-builder.md b/content/en/archived-docs/corda-os/4.9/network-builder.md index a8ec2902bd3..200d53aedf6 100644 --- a/content/en/archived-docs/corda-os/4.9/network-builder.md +++ b/content/en/archived-docs/corda-os/4.9/network-builder.md @@ -21,7 +21,7 @@ title: Corda Network Builder The Corda Network Builder is a tool for building Corda networks for testing purposes. It leverages Docker and containers to abstract the complexity of managing a distributed network away from the user. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} The network you build will either be made up of local `Docker` nodes *or* of nodes spread across Azure containers. For each node a separate Docker image is built based on [corda/corda-zulu-java1.8-4.4](https://hub.docker.com/r/corda/corda-zulu-java1.8-4.4). diff --git a/content/en/archived-docs/corda-os/4.9/node-administration.md b/content/en/archived-docs/corda-os/4.9/node-administration.md index 0f8836bc91e..07985990abb 100644 --- a/content/en/archived-docs/corda-os/4.9/node-administration.md +++ b/content/en/archived-docs/corda-os/4.9/node-administration.md @@ -172,7 +172,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ## Memory usage and tuning diff --git a/content/en/archived-docs/corda-os/4.9/node-database-tables.md b/content/en/archived-docs/corda-os/4.9/node-database-tables.md index 7815c788a09..3ead53a61a5 100644 --- a/content/en/archived-docs/corda-os/4.9/node-database-tables.md +++ b/content/en/archived-docs/corda-os/4.9/node-database-tables.md @@ -49,7 +49,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more here: [The network map](network-map.md) -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -177,7 +177,7 @@ Read more in [the ledger](key-concepts-ledger.md) ### Attachments Read more in [Working with attachments]({{< relref "../enterprise/get-started/tutorials/supplementary-tutorials/tutorial-attachments.md" >}}) and [Node services](node-services.md) -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -468,7 +468,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -497,7 +497,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/archived-docs/corda-os/4.9/permissioning.md b/content/en/archived-docs/corda-os/4.9/permissioning.md index 8ea89408452..7533dda5239 100644 --- a/content/en/archived-docs/corda-os/4.9/permissioning.md +++ b/content/en/archived-docs/corda-os/4.9/permissioning.md @@ -52,7 +52,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/archived-docs/corda-os/4.9/upgrading-cordapps.md b/content/en/archived-docs/corda-os/4.9/upgrading-cordapps.md index 2f177c374a7..5d8bf1bbf6c 100644 --- a/content/en/archived-docs/corda-os/4.9/upgrading-cordapps.md +++ b/content/en/archived-docs/corda-os/4.9/upgrading-cordapps.md @@ -74,7 +74,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="/en/images/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="/en/images/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/platform/corda/1.3/cenm/sub-zones.md b/content/en/platform/corda/1.3/cenm/sub-zones.md index 33c6a88bddc..ecdb314eb49 100644 --- a/content/en/platform/corda/1.3/cenm/sub-zones.md +++ b/content/en/platform/corda/1.3/cenm/sub-zones.md @@ -27,10 +27,9 @@ to connect to. It has no comprehension of subzones. It simply connects to the se configuration file and, once registered with both, interacts with other nodes and the apps deployed upon it via the RPC clients. This is summarised below: -{{< - figure +{{< figure src="resources/node-zone-view.png" - zoom="resources/node-zone-view.png" + width=90% figcaption="Network from a node's Perspective" alt="node zone view" @@ -44,10 +43,9 @@ registered with itself. From the perspective of the operator of that zone however, things are a lot more interesting: -{{< - figure +{{< figure src="resources/simple-subzones.png" - zoom="resources/simple-subzones.png" + width=110% figcaption="Network from a Zone's Perspective" alt="simple subzones" @@ -86,10 +84,9 @@ is transferred from the notary operator to the zone operator. This is shown in the following diagram: -{{< - figure +{{< figure src="resources/simple-seg-zones.png" - zoom="resources/simple-seg-zones.png" + width=110% figcaption="Segregated Subzones" alt="segregated subzones" diff --git a/content/en/platform/corda/1.4/cenm/signing-service.md b/content/en/platform/corda/1.4/cenm/signing-service.md index 3abcdd080e2..3610e87eb0b 100644 --- a/content/en/platform/corda/1.4/cenm/signing-service.md +++ b/content/en/platform/corda/1.4/cenm/signing-service.md @@ -1848,7 +1848,7 @@ the Corda node will join the network. If any of the pending requests fails, it is not persisted and is removed from the pending requests. -{{< figure zoom="./resources/example-ca-plugin-diagram.png" width="800" title="Example CA plug-in diagram (click to zoom)" alt="Example CA plug-in diagram" >}} +{{< figure src="./resources/example-ca-plugin-diagram.png" width="800" title="Example CA plug-in diagram (click to zoom)" alt="Example CA plug-in diagram" >}} An example third-party signer is also attached. It uses a Signing Service configuration to sign the data stored inside the example CA plug-in. diff --git a/content/en/platform/corda/1.4/cenm/sub-zones.md b/content/en/platform/corda/1.4/cenm/sub-zones.md index 8854e251eb0..1cfcc9da071 100644 --- a/content/en/platform/corda/1.4/cenm/sub-zones.md +++ b/content/en/platform/corda/1.4/cenm/sub-zones.md @@ -27,10 +27,9 @@ to connect to. It has no comprehension of subzones. It simply connects to the se configuration file and, once registered with both, interacts with other nodes and the apps deployed upon it via the RPC clients. This is summarised below: -{{< - figure +{{< figure src="resources/node-zone-view.png" - zoom="resources/node-zone-view.png" + width=90% figcaption="Network from a node's Perspective" alt="node zone view" @@ -44,10 +43,9 @@ registered with itself. From the perspective of the operator of that zone however, things are a lot more interesting: -{{< - figure +{{< figure src="resources/simple-subzones.png" - zoom="resources/simple-subzones.png" + width=110% figcaption="Network from a Zone's Perspective" alt="simple subzones" @@ -86,10 +84,9 @@ is transferred from the notary operator to the zone operator. This is shown in the following diagram: -{{< - figure +{{< figure src="resources/simple-seg-zones.png" - zoom="resources/simple-seg-zones.png" + width=110% figcaption="Segregated Subzones" alt="segregated subzones" diff --git a/content/en/platform/corda/1.5/cenm/cenm-console.md b/content/en/platform/corda/1.5/cenm/cenm-console.md index 203305d9e56..ce8673b2024 100644 --- a/content/en/platform/corda/1.5/cenm/cenm-console.md +++ b/content/en/platform/corda/1.5/cenm/cenm-console.md @@ -107,15 +107,15 @@ To access the CENM management console: 2. On the login screen, enter your user login credentials: -{{< figure zoom="/en/images/cenm-management-console-login-screen.png" alt="CENM management console login screen" >}} +{{< figure src="/en/images/cenm-management-console-login-screen.png" alt="CENM management console login screen" >}} 3. Select **CENM CONSOLE**. -{{< figure zoom="/en/images/cenm-management-console-launcher.png" alt="CENM management console launcher screen" >}} +{{< figure src="/en/images/cenm-management-console-launcher.png" alt="CENM management console launcher screen" >}} The CENM management console loads on the **NETWORK MAP** Service screen. -{{< figure zoom="/en/images/cenm-management-console-network-map-list-screen.png" alt="CENM management console Network Map Service screen" >}} +{{< figure src="/en/images/cenm-management-console-network-map-list-screen.png" alt="CENM management console Network Map Service screen" >}} ### Explore the Network Map Service @@ -127,7 +127,7 @@ The default Network Map view is called **LAYOUT VIEW** - this is what you see wh There is also a **MAP VIEW**, which shows the Network Map as an actual map grid: -{{< figure zoom="/en/images/cenm-management-console-map-view.png" alt="CENM management console - Map View" >}} +{{< figure src="/en/images/cenm-management-console-map-view.png" alt="CENM management console - Map View" >}} You can switch between the two views by selecting **MAP VIEW**/**LAYOUT VIEW** respectively from the drop-down menu that opens when you click on your username in the top right corner of the screen: @@ -137,17 +137,17 @@ You can switch between the two views by selecting **MAP VIEW**/**LAYOUT VIEW** r To view the status and any pending changes to the Network Parameters, or to make new updates, click **NETWORK PARAMETERS** in the top navigation area of the screen. The Network Parameters view shows the current network parameters in the **CURRENT PARAMETERS** tab: -{{< figure zoom="/en/images/cenm-management-console-net-params-current-only.png" alt="CENM management console - Network Parameters" >}} +{{< figure src="/en/images/cenm-management-console-net-params-current-only.png" alt="CENM management console - Network Parameters" >}} If there are pending updates, you will see them in the **PENDING UPDATE** tab: -{{< figure zoom="/en/images/cenm-management-console-net-params.png" alt="CENM management console - Network Parameters" >}} +{{< figure src="/en/images/cenm-management-console-net-params.png" alt="CENM management console - Network Parameters" >}} To update the Network Parameters: 1. On the **NETWORK PARAMETERS** screen, scroll to the bottom and click **START UPDATE PROCESS** to open the **Network Parameters Update** form view: -{{< figure zoom="/en/images/cenm-management-console-net-params-update-started.png" alt="CENM management console - Network Parameters" >}} +{{< figure src="/en/images/cenm-management-console-net-params-update-started.png" alt="CENM management console - Network Parameters" >}} 2. Give a name to the update in the **ABOUT THE UPDATE** field. @@ -155,7 +155,7 @@ To update the Network Parameters: 4. Make the required changes in the **BASIC PARAMETERS** fields. Alternatively, to make the changes in a command-line interface within the console, select the **CODE VIEW** in the top right corner of the screen: -{{< figure zoom="/en/images/cenm-management-console-net-params-code-view.png" alt="CENM management console - Network Parameters" >}} +{{< figure src="/en/images/cenm-management-console-net-params-code-view.png" alt="CENM management console - Network Parameters" >}} 5. If required, add a Notary to the update in the **NOTARIES** section. @@ -163,11 +163,11 @@ To update the Network Parameters: Now that the update has been scheduled, click **ADVERTISE UPDATE** to advertise the update: -{{< figure zoom="/en/images/cenm-management-console-net-params-advertise.png" alt="CENM management console - Network Parameters - advertise update" >}} +{{< figure src="/en/images/cenm-management-console-net-params-advertise.png" alt="CENM management console - Network Parameters - advertise update" >}} 7. Once you have updated the parameters, scroll down and click **ADVERTISE UPDATE** again to advertise the parameters update: -{{< figure zoom="/en/images/cenm-management-console-net-params-advertise-params.png" alt="CENM management console - Network Parameters - advertise parameters update" >}} +{{< figure src="/en/images/cenm-management-console-net-params-advertise-params.png" alt="CENM management console - Network Parameters - advertise parameters update" >}} 8. You can now see the nodes that have accepted the update, and those that are still pending. @@ -175,23 +175,23 @@ To update the Network Parameters: 9. Scroll down and click **Execute Flag Day**: -{{< figure zoom="/en/images/cenm-management-console-net-params-acceptance.png" alt="CENM management console - Network Parameters - execute Flag Day" >}} +{{< figure src="/en/images/cenm-management-console-net-params-acceptance.png" alt="CENM management console - Network Parameters - execute Flag Day" >}} ### Check Identity Manager Service status and progress To access the Identity Manager Service, click **IDENTITY MANAGER** in the top navigation area of the screen. A list of CSR requests and their statuses is shown in the **CSR STATUS** tab: -{{< figure zoom="/en/images/cenm-management-console-identity-manager-csr-status.png" alt="CENM management console - Identity Manager Service" >}} +{{< figure src="/en/images/cenm-management-console-identity-manager-csr-status.png" alt="CENM management console - Identity Manager Service" >}} #### Check CSR (onboarding) and CRL (removal) status To check the status of members being onboarded to the network, click the **CSR STATUS** tab. You can see the status tag, and details of the request like the Request ID and legal name of the prospective member: -{{< figure zoom="/en/images/cenm-management-console-identity-manager-csr-status-open.png" alt="CENM management console - Identity Manager Service" >}} +{{< figure src="/en/images/cenm-management-console-identity-manager-csr-status-open.png" alt="CENM management console - Identity Manager Service" >}} To check the status of members being removed from the network, click the **CRR/CRL STATUS** tab. You can view the status tag for the removal progress, and details of the membership: -{{< figure zoom="/en/images/cenm-management-console-identity-manager-crr-crl-status-open.png" alt="CENM management console - Identity Manager Service" >}} +{{< figure src="/en/images/cenm-management-console-identity-manager-crr-crl-status-open.png" alt="CENM management console - Identity Manager Service" >}} ### Update services configuration files @@ -201,16 +201,16 @@ You can access and edit the configuration files of the Identity Manager Service, To access and edit the configuration files of the Identity Manager Service, click **CONFIGURATION** in the top navigation area of the screen, and then the **IDENTITY MANAGER** tab: -{{< figure zoom="/en/images/cenm-management-console-configuration-identity-manager.png" alt="CENM management console - Identity Manager Service configuration" >}} +{{< figure src="/en/images/cenm-management-console-configuration-identity-manager.png" alt="CENM management console - Identity Manager Service configuration" >}} #### Signing Service configuration To access and edit the configuration files of the Identity Manager Service, click **CONFIGURATION** in the top navigation area of the screen, and then the **SIGNER** tab: -{{< figure zoom="/en/images/cenm-management-console-configuration-signer.png" alt="CENM management console - Signing Service configuration" >}} +{{< figure src="/en/images/cenm-management-console-configuration-signer.png" alt="CENM management console - Signing Service configuration" >}} #### Network Map service configuration To access and edit the configuration files of the Identity Manager Service, click **CONFIGURATION** in the top navigation area of the screen, and then the **NETWORK MAP** tab: -{{< figure zoom="/en/images/cenm-management-console-configuration-network-map.png" alt="CENM management console - Network Map configuration" >}} +{{< figure src="/en/images/cenm-management-console-configuration-network-map.png" alt="CENM management console - Network Map configuration" >}} diff --git a/content/en/platform/corda/1.5/cenm/signing-service.md b/content/en/platform/corda/1.5/cenm/signing-service.md index 2d80eabc51a..b3a4d2d2da2 100644 --- a/content/en/platform/corda/1.5/cenm/signing-service.md +++ b/content/en/platform/corda/1.5/cenm/signing-service.md @@ -1848,7 +1848,7 @@ the Corda node will join the network. If any of the pending requests fails, it is not persisted and is removed from the pending requests. -{{< figure zoom="./resources/example-ca-plugin-diagram.png" width="800" title="Example CA plug-in diagram (click to zoom)" alt="Example CA plug-in diagram" >}} +{{< figure src="./resources/example-ca-plugin-diagram.png" width="800" title="Example CA plug-in diagram (click to zoom)" alt="Example CA plug-in diagram" >}} An example third-party signer is also attached. It uses a Signing Service configuration to sign the data stored inside the example CA plug-in. diff --git a/content/en/platform/corda/1.5/cenm/sub-zones.md b/content/en/platform/corda/1.5/cenm/sub-zones.md index 4f3581dfa96..b861390ea2c 100644 --- a/content/en/platform/corda/1.5/cenm/sub-zones.md +++ b/content/en/platform/corda/1.5/cenm/sub-zones.md @@ -27,10 +27,9 @@ to connect to. It has no comprehension of subzones. It simply connects to the se configuration file and, once registered with both, interacts with other nodes and the apps deployed upon it via the RPC clients. This is summarised below: -{{< - figure +{{< figure src="resources/node-zone-view.png" - zoom="resources/node-zone-view.png" + width=90% figcaption="Network from a node's Perspective" alt="node zone view" @@ -44,10 +43,9 @@ registered with itself. From the perspective of the operator of that zone however, things are a lot more interesting: -{{< - figure +{{< figure src="resources/simple-subzones.png" - zoom="resources/simple-subzones.png" + width=110% figcaption="Network from a Zone's Perspective" alt="simple subzones" @@ -86,10 +84,9 @@ is transferred from the notary operator to the zone operator. This is shown in the following diagram: -{{< - figure +{{< figure src="resources/simple-seg-zones.png" - zoom="resources/simple-seg-zones.png" + width=110% figcaption="Segregated Subzones" alt="segregated subzones" diff --git a/content/en/platform/corda/1.6/cenm/cenm-console.md b/content/en/platform/corda/1.6/cenm/cenm-console.md index 7011835cc6b..ca86d5a72d5 100644 --- a/content/en/platform/corda/1.6/cenm/cenm-console.md +++ b/content/en/platform/corda/1.6/cenm/cenm-console.md @@ -107,15 +107,15 @@ To access the CENM management console: 2. On the login screen, enter your user login credentials: -{{< figure zoom="/en/images/cenm-management-console-login-screen.png" alt="CENM management console login screen" >}} +{{< figure src="/en/images/cenm-management-console-login-screen.png" alt="CENM management console login screen" >}} 3. Select **CENM CONSOLE**. -{{< figure zoom="/en/images/cenm-management-console-launcher.png" alt="CENM management console launcher screen" >}} +{{< figure src="/en/images/cenm-management-console-launcher.png" alt="CENM management console launcher screen" >}} The CENM management console loads on the **NETWORK MAP** Service screen. -{{< figure zoom="/en/images/cenm-management-console-network-map-list-screen.png" alt="CENM management console Network Map Service screen" >}} +{{< figure src="/en/images/cenm-management-console-network-map-list-screen.png" alt="CENM management console Network Map Service screen" >}} ### Explore the Network Map Service @@ -127,7 +127,7 @@ The default Network Map view is called **LAYOUT VIEW** - this is what you see wh There is also a **MAP VIEW**, which shows the Network Map as an actual map grid: -{{< figure zoom="/en/images/cenm-management-console-map-view.png" alt="CENM management console - Map View" >}} +{{< figure src="/en/images/cenm-management-console-map-view.png" alt="CENM management console - Map View" >}} You can switch between the two views by selecting **MAP VIEW**/**LAYOUT VIEW** respectively from the drop-down menu that opens when you click on your username in the top right corner of the screen: @@ -137,17 +137,17 @@ You can switch between the two views by selecting **MAP VIEW**/**LAYOUT VIEW** r To view the status and any pending changes to the Network Parameters, or to make new updates, click **NETWORK PARAMETERS** in the top navigation area of the screen. The Network Parameters view shows the current network parameters in the **CURRENT PARAMETERS** tab: -{{< figure zoom="/en/images/cenm-management-console-net-params-current-only.png" alt="CENM management console - Network Parameters" >}} +{{< figure src="/en/images/cenm-management-console-net-params-current-only.png" alt="CENM management console - Network Parameters" >}} If there are pending updates, you will see them in the **PENDING UPDATE** tab: -{{< figure zoom="/en/images/cenm-management-console-net-params.png" alt="CENM management console - Network Parameters" >}} +{{< figure src="/en/images/cenm-management-console-net-params.png" alt="CENM management console - Network Parameters" >}} To update the Network Parameters: 1. On the **NETWORK PARAMETERS** screen, scroll to the bottom and click **START UPDATE PROCESS** to open the **Network Parameters Update** form view: -{{< figure zoom="/en/images/cenm-management-console-net-params-update-started.png" alt="CENM management console - Network Parameters" >}} +{{< figure src="/en/images/cenm-management-console-net-params-update-started.png" alt="CENM management console - Network Parameters" >}} 2. Give a name to the update in the **ABOUT THE UPDATE** field. @@ -155,7 +155,7 @@ To update the Network Parameters: 4. Make the required changes in the **BASIC PARAMETERS** fields. Alternatively, to make the changes in a command-line interface within the console, select the **CODE VIEW** in the top right corner of the screen: -{{< figure zoom="/en/images/cenm-management-console-net-params-code-view.png" alt="CENM management console - Network Parameters" >}} +{{< figure src="/en/images/cenm-management-console-net-params-code-view.png" alt="CENM management console - Network Parameters" >}} 5. If required, add a Notary to the update in the **NOTARIES** section. @@ -163,11 +163,11 @@ To update the Network Parameters: Now that the update has been scheduled, click **ADVERTISE UPDATE** to advertise the update: -{{< figure zoom="/en/images/cenm-management-console-net-params-advertise.png" alt="CENM management console - Network Parameters - advertise update" >}} +{{< figure src="/en/images/cenm-management-console-net-params-advertise.png" alt="CENM management console - Network Parameters - advertise update" >}} 7. Once you have updated the parameters, scroll down and click **ADVERTISE UPDATE** again to advertise the parameters update: -{{< figure zoom="/en/images/cenm-management-console-net-params-advertise-params.png" alt="CENM management console - Network Parameters - advertise parameters update" >}} +{{< figure src="/en/images/cenm-management-console-net-params-advertise-params.png" alt="CENM management console - Network Parameters - advertise parameters update" >}} 8. You can now see the nodes that have accepted the update, and those that are still pending. @@ -175,23 +175,23 @@ To update the Network Parameters: 9. Scroll down and click **Execute Flag Day**: -{{< figure zoom="/en/images/cenm-management-console-net-params-acceptance.png" alt="CENM management console - Network Parameters - execute Flag Day" >}} +{{< figure src="/en/images/cenm-management-console-net-params-acceptance.png" alt="CENM management console - Network Parameters - execute Flag Day" >}} ### Check Identity Manager Service status and progress To access the Identity Manager Service, click **IDENTITY MANAGER** in the top navigation area of the screen. A list of CSR requests and their statuses is shown in the **CSR STATUS** tab: -{{< figure zoom="/en/images/cenm-management-console-identity-manager-csr-status.png" alt="CENM management console - Identity Manager Service" >}} +{{< figure src="/en/images/cenm-management-console-identity-manager-csr-status.png" alt="CENM management console - Identity Manager Service" >}} #### Check CSR (onboarding) and CRL (removal) status To check the status of members being onboarded to the network, click the **CSR STATUS** tab. You can see the status tag, and details of the request like the Request ID and legal name of the prospective member: -{{< figure zoom="/en/images/cenm-management-console-identity-manager-csr-status-open.png" alt="CENM management console - Identity Manager Service" >}} +{{< figure src="/en/images/cenm-management-console-identity-manager-csr-status-open.png" alt="CENM management console - Identity Manager Service" >}} To check the status of members being removed from the network, click the **CRR/CRL STATUS** tab. You can view the status tag for the removal progress, and details of the membership: -{{< figure zoom="/en/images/cenm-management-console-identity-manager-crr-crl-status-open.png" alt="CENM management console - Identity Manager Service" >}} +{{< figure src="/en/images/cenm-management-console-identity-manager-crr-crl-status-open.png" alt="CENM management console - Identity Manager Service" >}} ### Update services configuration files @@ -201,16 +201,16 @@ You can access and edit the configuration files of the Identity Manager Service, To access and edit the configuration files of the Identity Manager Service, click **CONFIGURATION** in the top navigation area of the screen, and then the **IDENTITY MANAGER** tab: -{{< figure zoom="/en/images/cenm-management-console-configuration-identity-manager.png" alt="CENM management console - Identity Manager Service configuration" >}} +{{< figure src="/en/images/cenm-management-console-configuration-identity-manager.png" alt="CENM management console - Identity Manager Service configuration" >}} #### Signing Service configuration To access and edit the configuration files of the Identity Manager Service, click **CONFIGURATION** in the top navigation area of the screen, and then the **SIGNER** tab: -{{< figure zoom="/en/images/cenm-management-console-configuration-signer.png" alt="CENM management console - Signing Service configuration" >}} +{{< figure src="/en/images/cenm-management-console-configuration-signer.png" alt="CENM management console - Signing Service configuration" >}} #### Network Map service configuration To access and edit the configuration files of the Identity Manager Service, click **CONFIGURATION** in the top navigation area of the screen, and then the **NETWORK MAP** tab: -{{< figure zoom="/en/images/cenm-management-console-configuration-network-map.png" alt="CENM management console - Network Map configuration" >}} +{{< figure src="/en/images/cenm-management-console-configuration-network-map.png" alt="CENM management console - Network Map configuration" >}} diff --git a/content/en/platform/corda/1.6/cenm/signing-service.md b/content/en/platform/corda/1.6/cenm/signing-service.md index 4f18d7d5601..a3c70883611 100644 --- a/content/en/platform/corda/1.6/cenm/signing-service.md +++ b/content/en/platform/corda/1.6/cenm/signing-service.md @@ -1916,7 +1916,7 @@ the Corda node will join the network. If any of the pending requests fails, it is not persisted and is removed from the pending requests. -{{< figure zoom="./resources/example-ca-plugin-diagram.png" width="800" title="Example CA plug-in diagram (click to zoom)" alt="Example CA plug-in diagram" >}} +{{< figure src="./resources/example-ca-plugin-diagram.png" width="800" title="Example CA plug-in diagram (click to zoom)" alt="Example CA plug-in diagram" >}} An example third-party signer is also attached. It uses a Signing Service configuration to sign the data stored inside the example CA plug-in. diff --git a/content/en/platform/corda/1.6/cenm/sub-zones.md b/content/en/platform/corda/1.6/cenm/sub-zones.md index 4e4703c84d2..702787e8af0 100644 --- a/content/en/platform/corda/1.6/cenm/sub-zones.md +++ b/content/en/platform/corda/1.6/cenm/sub-zones.md @@ -27,10 +27,9 @@ to connect to. It has no comprehension of subzones. It simply connects to the se configuration file and, once registered with both, interacts with other nodes and the apps deployed upon it via the RPC clients. This is summarised below: -{{< - figure +{{< figure src="resources/node-zone-view.png" - zoom="resources/node-zone-view.png" + width=90% figcaption="Network from a node's Perspective" alt="node zone view" @@ -44,10 +43,9 @@ registered with itself. From the perspective of the operator of that zone however, things are a lot more interesting: -{{< - figure +{{< figure src="resources/simple-subzones.png" - zoom="resources/simple-subzones.png" + width=110% figcaption="Network from a Zone's Perspective" alt="simple subzones" @@ -86,10 +84,9 @@ is transferred from the notary operator to the zone operator. This is shown in the following diagram: -{{< - figure +{{< figure src="resources/simple-seg-zones.png" - zoom="resources/simple-seg-zones.png" + width=110% figcaption="Segregated Subzones" alt="segregated subzones" diff --git a/content/en/platform/corda/1.7/cenm/cenm-console.md b/content/en/platform/corda/1.7/cenm/cenm-console.md index 793bdd8ccf8..fcbacf058d7 100644 --- a/content/en/platform/corda/1.7/cenm/cenm-console.md +++ b/content/en/platform/corda/1.7/cenm/cenm-console.md @@ -110,15 +110,15 @@ To access the CENM management console: 2. On the login screen, enter your user login credentials: - {{< figure zoom="/en/images/cenm-management-console-login-screen.png" alt="CENM management console login screen" >}} + {{< figure src="/en/images/cenm-management-console-login-screen.png" alt="CENM management console login screen" >}} 3. Select **CENM CONSOLE**. - {{< figure zoom="/en/images/cenm-management-console-launcher.png" alt="CENM management console launcher screen" >}} + {{< figure src="/en/images/cenm-management-console-launcher.png" alt="CENM management console launcher screen" >}} The CENM management console loads on the **NETWORK MAP** Service screen. -{{< figure zoom="/en/images/cenm-management-console-network-map-list-screen.png" alt="CENM management console Network Map Service screen" >}} +{{< figure src="/en/images/cenm-management-console-network-map-list-screen.png" alt="CENM management console Network Map Service screen" >}} ## Exploring the Network Map Service @@ -130,7 +130,7 @@ The default network map view is called **LAYOUT VIEW** - this is what you see wh There is also a **MAP VIEW**, which shows the Network Map as an actual map grid: -{{< figure zoom="/en/images/cenm-management-console-map-view.png" alt="CENM management console - Map View" >}} +{{< figure src="/en/images/cenm-management-console-map-view.png" alt="CENM management console - Map View" >}} You can switch between the two views by selecting **MAP VIEW**/**LAYOUT VIEW** respectively from the drop-down menu that opens when you click on your username in the top right corner of the screen: @@ -144,17 +144,17 @@ To view the status and any pending changes to the Network Parameters, or to make The Network Parameters view shows the current network parameters in the **CURRENT PARAMETERS** tab: -{{< figure zoom="/en/images/cenm-management-console-net-params-current-only.png" alt="CENM management console - Network Parameters" >}} +{{< figure src="/en/images/cenm-management-console-net-params-current-only.png" alt="CENM management console - Network Parameters" >}} If there are pending updates, you will see them in the **PENDING UPDATE** tab: -{{< figure zoom="/en/images/cenm-management-console-net-params.png" alt="CENM management console - Network Parameters" >}} +{{< figure src="/en/images/cenm-management-console-net-params.png" alt="CENM management console - Network Parameters" >}} To update the Network Parameters: 1. On the **NETWORK PARAMETERS** screen, scroll to the bottom and click **START UPDATE PROCESS** to open the **Network Parameters Update** form view: - {{< figure zoom="/en/images/cenm-management-console-net-params-update-started.png" alt="CENM management console - Network Parameters" >}} + {{< figure src="/en/images/cenm-management-console-net-params-update-started.png" alt="CENM management console - Network Parameters" >}} 2. Give a name to the update in the **ABOUT THE UPDATE** field. @@ -162,7 +162,7 @@ To update the Network Parameters: 4. Make the required changes in the **BASIC PARAMETERS** fields. Alternatively, to make the changes in a command-line interface within the console, select the **CODE VIEW** in the top right corner of the screen: - {{< figure zoom="/en/images/cenm-management-console-net-params-code-view.png" alt="CENM management console - Network Parameters" >}} + {{< figure src="/en/images/cenm-management-console-net-params-code-view.png" alt="CENM management console - Network Parameters" >}} 5. If required, add a Notary to the update in the **NOTARIES** section. @@ -170,11 +170,11 @@ To update the Network Parameters: 7. Now that the update has been scheduled, click **ADVERTISE UPDATE** to advertise the update: - {{< figure zoom="/en/images/cenm-management-console-net-params-advertise.png" alt="CENM management console - Network Parameters - advertise update" >}} + {{< figure src="/en/images/cenm-management-console-net-params-advertise.png" alt="CENM management console - Network Parameters - advertise update" >}} 8. Once you have updated the parameters, scroll down and click **ADVERTISE UPDATE** again to advertise the parameters update: - {{< figure zoom="/en/images/cenm-management-console-net-params-advertise-params.png" alt="CENM management console - Network Parameters - advertise parameters update" >}} + {{< figure src="/en/images/cenm-management-console-net-params-advertise-params.png" alt="CENM management console - Network Parameters - advertise parameters update" >}} 9. You can now see the nodes that have accepted the update, and those that are still pending. @@ -182,7 +182,7 @@ To update the Network Parameters: 9. Scroll down and click **Execute Flag Day**: -{{< figure zoom="/en/images/cenm-management-console-net-params-acceptance.png" alt="CENM management console - Network Parameters - execute Flag Day" >}} +{{< figure src="/en/images/cenm-management-console-net-params-acceptance.png" alt="CENM management console - Network Parameters - execute Flag Day" >}} ## Checking Identity Manager Service status and progress @@ -192,7 +192,7 @@ To access the Identity Manager Service: A list of CSR requests and their statuses is shown in the **CSR STATUS** tab: -{{< figure zoom="/en/images/cenm-management-console-identity-manager-csr-status.png" alt="CENM management console - Identity Manager Service" >}} +{{< figure src="/en/images/cenm-management-console-identity-manager-csr-status.png" alt="CENM management console - Identity Manager Service" >}} ### Checking CSR (onboarding) and CRL (removal) status @@ -202,7 +202,7 @@ To check the status of members being onboarded to the network: You can see the status tag, and details of the request like the Request ID and legal name of the prospective member: - {{< figure zoom="/en/images/cenm-management-console-identity-manager-csr-status-open.png" alt="CENM management console - Identity Manager Service" >}} + {{< figure src="/en/images/cenm-management-console-identity-manager-csr-status-open.png" alt="CENM management console - Identity Manager Service" >}} To check the status of members being removed from the network: @@ -210,7 +210,7 @@ To check the status of members being removed from the network: You can view the status tag for the removal progress, and details of the membership: - {{< figure zoom="/en/images/cenm-management-console-identity-manager-crr-crl-status-open.png" alt="CENM management console - Identity Manager Service" >}} + {{< figure src="/en/images/cenm-management-console-identity-manager-crr-crl-status-open.png" alt="CENM management console - Identity Manager Service" >}} ## Configuring services @@ -224,16 +224,16 @@ You can access and edit the configuration files of the: To access and edit the configuration files of the Identity Manager Service, click **CONFIGURATION** in the top navigation area of the screen, and then the **IDENTITY MANAGER** tab: -{{< figure zoom="/en/images/cenm-management-console-configuration-identity-manager.png" alt="CENM management console - Identity Manager Service configuration" >}} +{{< figure src="/en/images/cenm-management-console-configuration-identity-manager.png" alt="CENM management console - Identity Manager Service configuration" >}} ### Configuring the Signing Service To access and edit the configuration files of the Identity Manager Service, click **CONFIGURATION** in the top navigation area of the screen, and then the **SIGNER** tab: -{{< figure zoom="/en/images/cenm-management-console-configuration-signer.png" alt="CENM management console - Signing Service configuration" >}} +{{< figure src="/en/images/cenm-management-console-configuration-signer.png" alt="CENM management console - Signing Service configuration" >}} ### Configuring the Network Map Service To access and edit the configuration files of the Identity Manager Service, click **CONFIGURATION** in the top navigation area of the screen, and then the **NETWORK MAP** tab: -{{< figure zoom="/en/images/cenm-management-console-configuration-network-map.png" alt="CENM management console - Network Map configuration" >}} +{{< figure src="/en/images/cenm-management-console-configuration-network-map.png" alt="CENM management console - Network Map configuration" >}} diff --git a/content/en/platform/corda/1.7/cenm/signing-service.md b/content/en/platform/corda/1.7/cenm/signing-service.md index 7dc1df5bfda..76168e71db5 100644 --- a/content/en/platform/corda/1.7/cenm/signing-service.md +++ b/content/en/platform/corda/1.7/cenm/signing-service.md @@ -1915,7 +1915,7 @@ the Corda node will join the network. If any of the pending requests fails, it is not persisted and is removed from the pending requests. -{{< figure zoom="./resources/example-ca-plugin-diagram.png" width="800" title="Example CA plug-in diagram (click to zoom)" alt="Example CA plug-in diagram" >}} +{{< figure src="./resources/example-ca-plugin-diagram.png" width="800" title="Example CA plug-in diagram (click to zoom)" alt="Example CA plug-in diagram" >}} An example third-party signer is also attached. It uses a Signing Service configuration to sign the data stored inside the example CA plug-in. diff --git a/content/en/platform/corda/1.7/cenm/sub-zones.md b/content/en/platform/corda/1.7/cenm/sub-zones.md index 1277e5266c2..c18d6e3fe52 100644 --- a/content/en/platform/corda/1.7/cenm/sub-zones.md +++ b/content/en/platform/corda/1.7/cenm/sub-zones.md @@ -27,10 +27,9 @@ to connect to. It has no comprehension of subzones. It simply connects to the se configuration file and, once registered with both, interacts with other nodes and the apps deployed upon it via the RPC clients. This is summarised below: -{{< - figure +{{< figure src="resources/node-zone-view.png" - zoom="resources/node-zone-view.png" + width=90% figcaption="Network from a node's Perspective" alt="node zone view" @@ -44,10 +43,9 @@ registered with itself. From the perspective of the operator of that zone however, things are a lot more interesting: -{{< - figure +{{< figure src="resources/simple-subzones.png" - zoom="resources/simple-subzones.png" + width=110% figcaption="Network from a Zone's Perspective" alt="simple subzones" @@ -86,10 +84,9 @@ is transferred from the notary operator to the zone operator. This is shown in the following diagram: -{{< - figure +{{< figure src="resources/simple-seg-zones.png" - zoom="resources/simple-seg-zones.png" + width=110% figcaption="Segregated Subzones" alt="segregated subzones" diff --git a/content/en/platform/corda/4.10/community/api-core-types.md b/content/en/platform/corda/4.10/community/api-core-types.md index 3212454ad9a..e38cf666eae 100644 --- a/content/en/platform/corda/4.10/community/api-core-types.md +++ b/content/en/platform/corda/4.10/community/api-core-types.md @@ -74,11 +74,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="./resources/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="./resources/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="./resources/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="./resources/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/platform/corda/4.10/community/api-flows.md b/content/en/platform/corda/4.10/community/api-flows.md index 29722b50577..478e13cfd1d 100644 --- a/content/en/platform/corda/4.10/community/api-flows.md +++ b/content/en/platform/corda/4.10/community/api-flows.md @@ -91,7 +91,7 @@ The `initiator`: You can visualize the work performed by initiator like this: -{{< figure alt="flow overview" width=80% zoom="./resources/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="./resources/flow-overview.png" >}} ## Responder flow class example diff --git a/content/en/platform/corda/4.10/community/api-states.md b/content/en/platform/corda/4.10/community/api-states.md index a990674f818..1eb3667525d 100644 --- a/content/en/platform/corda/4.10/community/api-states.md +++ b/content/en/platform/corda/4.10/community/api-states.md @@ -68,7 +68,7 @@ common sub-interfaces are `LinearState` and `OwnableState`. You can visualize the hierarchy like this: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/how-to.md b/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/how-to.md index 21476c01032..1f54d0b8a22 100644 --- a/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/how-to.md +++ b/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/how-to.md @@ -70,7 +70,7 @@ Follow these steps to create a new customer profile. When the customer profile is created, they will not have any accounts - you will have to create them. Learn how under [Creating accounts](#create-a-current-account). {{< /note >}} -{{< figure alt="Create customer profile" width=80% zoom="/en/gifs/create-customer-biab-1.0.gif" >}} +{{< figure alt="Create customer profile" width=80% src="/en/gifs/create-customer-biab-1.0.gif" >}} ### Create a Current account @@ -94,7 +94,7 @@ When the customer profile is created, they will not have any accounts - you will 7. When an account is created, it is in **PENDING** status. This must be changed to **ACTIVE** for a customer to be able to interact with and use the account. See [Change an account status](#change-an-account-status) for more information. -{{< figure alt="Create account" width=80% zoom="/en/gifs/create-current-account-biab-1.0.gif" >}} +{{< figure alt="Create account" width=80% src="/en/gifs/create-current-account-biab-1.0.gif" >}} ### Create a Savings account @@ -140,7 +140,7 @@ An account has three statuses: **PENDING**, **ACTIVE**, and **SUSPENDED**. When If the account needs to be suspended, follow the same steps but select **SUSPENDED**. -{{< figure alt="Set account status" width=80% zoom="/en/gifs/set-account-status-biab-1.0.gif" >}} +{{< figure alt="Set account status" width=80% src="/en/gifs/set-account-status-biab-1.0.gif" >}} ### Assign or revoke a user role @@ -163,7 +163,7 @@ To assign a user role, follow these steps: 5. Click **Revoke**. A message will appear indicating that the user role was assigned successfully. -{{< figure alt="Assign role" width=80% zoom="/en/gifs/assign-a-role-biab-1.0.gif" >}} +{{< figure alt="Assign role" width=80% src="/en/gifs/assign-a-role-biab-1.0.gif" >}} #### Revoke a user role @@ -179,7 +179,7 @@ To revoke a user role, follow these steps: 5. Click **Save**. A message will appear indicating that the user role was revoked successfully. -{{< figure alt="Revoke role" width=80% zoom="/en/gifs/revoke-role-biab-1.0.gif" >}} +{{< figure alt="Revoke role" width=80% src="/en/gifs/revoke-role-biab-1.0.gif" >}} ### Issue a loan @@ -195,7 +195,7 @@ Once the account has been set to **ACTIVE**, you will have the ability to issue A loan account is created when a loan has been issued successfully. -{{< figure alt="Issue loan" width=80% zoom="/en/gifs/issue-loan-biab-1.0.gif" >}} +{{< figure alt="Issue loan" width=80% src="/en/gifs/issue-loan-biab-1.0.gif" >}} ### Approve overdrafts @@ -215,7 +215,7 @@ To approve an overdraft, follow these steps. Overdrafts can be approved whether the account is **PENDING**, **ACTIVE**, or **SUSPENDED**. {{< /note >}} -{{< figure alt="Approve overdraft" width=80% zoom="/en/gifs/approve-overdraft-biab-1.0.gif" >}} +{{< figure alt="Approve overdraft" width=80% src="/en/gifs/approve-overdraft-biab-1.0.gif" >}} ### Deposit money to an account @@ -230,7 +230,7 @@ Follow these steps to deposit money to a customer account. 4. Click **Save**. You will receive a message indicating that the deposit was successful. -{{< figure alt="Deposit" width=80% zoom="/en/gifs/deposit-biab-1.0.gif" >}} +{{< figure alt="Deposit" width=80% src="/en/gifs/deposit-biab-1.0.gif" >}} ### Register as a user on Bank in a Box @@ -251,7 +251,7 @@ You must be registered as a **Customer** or **Admin** on Bank in a Box to perfor 5. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update customer profile @@ -284,7 +284,7 @@ An **Admin user** can set an account's **Withdrawal daily limit** or **Transfer 2. Click **Save** when you have entered the desired limits. A message will appear indicating that the limits have been saved successfully. -{{< figure alt="Set withdrawal and transfer limits - admin" width=80% zoom="/en/gifs/set-limits-admin-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - admin" width=80% src="/en/gifs/set-limits-admin-biab-1.0.gif" >}} ## Customer tasks @@ -309,12 +309,12 @@ Follow these steps to create a new intrabank payment. 6. Click **Save**. You will receive a notification indicating that the payment was created successfully. You will also receive notifications indicating any changes in your account balances. -{{< figure alt="Create intrabank payment" width=80% zoom="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} +{{< figure alt="Create intrabank payment" width=80% src="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} After making a payment, you can view the details of this transaction on the Transactions screen. -{{< figure alt="View transaction" width="800" width=80% zoom="/en/gifs/view-transaction-biab-1.0.gif" >}} +{{< figure alt="View transaction" width="800" width=80% src="/en/gifs/view-transaction-biab-1.0.gif" >}} ### Create a recurring payment @@ -338,7 +338,7 @@ Follow these steps to create a recurring payment: 3. You will be taken back to the **Recurring payments screen** where you will receive a message indicating that the recurring payment was created successfully. -{{< figure alt="Recurring payment" width=80% zoom="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} +{{< figure alt="Recurring payment" width=80% src="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} {{< note >}} This payment will not appear on the **Recurring payments screen** until the first iteration has occurred. @@ -367,7 +367,7 @@ You must be registered as a Customer or Admin on Bank in a Box to perform tasks. 7. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update a customer profile @@ -406,4 +406,4 @@ To set these limits as a **Customer**, follow these steps. 4. Click **Save**. You will be taken back to the Account page where you will receive a message indicating that the limits have been updated successfully. -{{< figure alt="Set withdrawal and transfer limits - customer" width=80% zoom="/en/gifs/set-limits-customer-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - customer" width=80% src="/en/gifs/set-limits-customer-biab-1.0.gif" >}} diff --git a/content/en/platform/corda/4.10/community/building-the-docs.md b/content/en/platform/corda/4.10/community/building-the-docs.md index 5e86e3b0c61..64ca0150f8b 100644 --- a/content/en/platform/corda/4.10/community/building-the-docs.md +++ b/content/en/platform/corda/4.10/community/building-the-docs.md @@ -76,7 +76,7 @@ Or if you want to use Docker: As a result, there will be an extra icon in the title bar of your local docs site, which should open the current page in Visual Studio Code: -{{< figure alt="Visual Studio Code" width=80% zoom="/en/images/hugo-vscode-page-edit.png" >}} +{{< figure alt="Visual Studio Code" width=80% src="/en/images/hugo-vscode-page-edit.png" >}} ## Edit web pages directly in Atom diff --git a/content/en/platform/corda/4.10/community/cipher-suites.md b/content/en/platform/corda/4.10/community/cipher-suites.md index 75a18f02c02..1c16fb15ff1 100644 --- a/content/en/platform/corda/4.10/community/cipher-suites.md +++ b/content/en/platform/corda/4.10/community/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates]({{< relref "permissioning.md" >}})): -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/platform/corda/4.10/community/contract-irs.md b/content/en/platform/corda/4.10/community/contract-irs.md index 283356fc6be..78fdccf4e6b 100644 --- a/content/en/platform/corda/4.10/community/contract-irs.md +++ b/content/en/platform/corda/4.10/community/contract-irs.md @@ -48,7 +48,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="/en/images/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="/en/images/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/platform/corda/4.10/community/cordapp-advanced-concepts.md b/content/en/platform/corda/4.10/community/cordapp-advanced-concepts.md index 617b89f273a..48f49064661 100644 --- a/content/en/platform/corda/4.10/community/cordapp-advanced-concepts.md +++ b/content/en/platform/corda/4.10/community/cordapp-advanced-concepts.md @@ -73,7 +73,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/platform/corda/4.10/community/cordapp-overview.md b/content/en/platform/corda/4.10/community/cordapp-overview.md index f001b3ff821..e52f87df871 100644 --- a/content/en/platform/corda/4.10/community/cordapp-overview.md +++ b/content/en/platform/corda/4.10/community/cordapp-overview.md @@ -22,7 +22,7 @@ CorDapps (Corda Distributed Applications) are distributed applications that run CorDapp is to allow nodes to reach agreement on updates to the ledger. They achieve this goal by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="/en/images/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="/en/images/node-diagram.png" >}} ## CorDapp components diff --git a/content/en/platform/corda/4.10/community/financial-model.md b/content/en/platform/corda/4.10/community/financial-model.md index 58569e3564b..2b3275bc7e1 100644 --- a/content/en/platform/corda/4.10/community/financial-model.md +++ b/content/en/platform/corda/4.10/community/financial-model.md @@ -93,6 +93,6 @@ countable (in cents), barrels of West Texas crude are fungible and countable (oi container), shares of the same class in a specific company are fungible and countable, and so on. The following diagram illustrates the complete Contract State hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Note there are currently two packages, a core library and a finance model specific library. Developers may re-use or extend the Finance types directly or write their own by extending the base types from the Core library. diff --git a/content/en/platform/corda/4.10/community/key-concepts-consensus.md b/content/en/platform/corda/4.10/community/key-concepts-consensus.md index a82abdeced6..5390ebc7b65 100644 --- a/content/en/platform/corda/4.10/community/key-concepts-consensus.md +++ b/content/en/platform/corda/4.10/community/key-concepts-consensus.md @@ -49,7 +49,7 @@ transferring a treasury bond, the bond transfer is only valid if: Walking the chain for this transaction would look like this: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a node may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer. The @@ -68,7 +68,7 @@ proposals: Both transactions will achieve validity consensus, yet Alice has managed to “double-spend” her USD to get double the amount of GBP and EUR: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/platform/corda/4.10/community/key-concepts-contracts.md b/content/en/platform/corda/4.10/community/key-concepts-contracts.md index a93d3d2c445..34cc164cd1a 100644 --- a/content/en/platform/corda/4.10/community/key-concepts-contracts.md +++ b/content/en/platform/corda/4.10/community/key-concepts-contracts.md @@ -55,7 +55,7 @@ transaction gathers all the required signatures, it cannot be executed unless it Each transaction [state]({{< relref "key-concepts-states.md" >}}) specifies a *contract type*. The contract specified takes the transaction as input, and determines if the transaction is valid based on the contract's internal rules. The contract must evaluate every input state and every output state. -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code can: * Check the number of inputs, outputs, commands, or attachments. diff --git a/content/en/platform/corda/4.10/community/key-concepts-ecosystem.md b/content/en/platform/corda/4.10/community/key-concepts-ecosystem.md index 2f13b0c6903..25b7b0f6430 100644 --- a/content/en/platform/corda/4.10/community/key-concepts-ecosystem.md +++ b/content/en/platform/corda/4.10/community/key-concepts-ecosystem.md @@ -32,7 +32,7 @@ title: Networks, identity, and discovery ## What is a network? On Corda, people and business interact by communicating over a peer-to-peer network of [Corda nodes]({{< relref "key-concepts-node.md" >}}). Each node represents a legal entity running Corda and one or more Corda distributed applications, known as [CorDapps]({{< relref "cordapp-overview.md" >}}). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} Corda is different from other distributed ledgers because all communication between nodes is point-to-point, and only shared on a need-to-know basis. It is also encrypted using transport-layer security. There are *no global broadcasts* to all parties on a network, but all of the nodes in a network can send messages directly to other nodes. If the recipient is offline, the message waits in an outbound queue until they are online again—just like an email. ## Join a network diff --git a/content/en/platform/corda/4.10/community/key-concepts-flows.md b/content/en/platform/corda/4.10/community/key-concepts-flows.md index 2d392818de0..839ad2c6b56 100644 --- a/content/en/platform/corda/4.10/community/key-concepts-flows.md +++ b/content/en/platform/corda/4.10/community/key-concepts-flows.md @@ -35,7 +35,7 @@ must specify what information needs to be sent, to which counterparties, and in Here is a visualisation of Alice and Bob agreeing a ledger update using this process: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -44,7 +44,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is a diagram showing the flow's steps used between Alice and Bob to perform the ledger update: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/platform/corda/4.10/community/key-concepts-ledger.md b/content/en/platform/corda/4.10/community/key-concepts-ledger.md index 745f79c6a84..4b19c95c100 100644 --- a/content/en/platform/corda/4.10/community/key-concepts-ledger.md +++ b/content/en/platform/corda/4.10/community/key-concepts-ledger.md @@ -39,7 +39,7 @@ loan are Alice and Bob, then they are the only nodes that ever see or store this This diagram shows a network with five nodes (Alice, Bob, Carl, Demi, and Ed). Each numbered circle on an intersection represents a fact shared between two or more nodes: -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} In the diagram, facts 1 and 7 are known by both Alice and Bob. Alice only shares facts with Bob, Alice doesn't share any facts with Carl, Demi, or Ed. @@ -56,7 +56,7 @@ each node maintains its own vault, which contains all of its known facts. You can think of a vault as being a database or simple table. In this diagram, facts 1 and 7 appear on both Alice's vault and Bob's vault, and are therefore shared facts: -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} When multiple nodes on a network share an evolving fact, the changes to the fact update at the same time in each node's vault. This means that Alice and Bob will both see an *identical version* of shared facts 1 and 7. diff --git a/content/en/platform/corda/4.10/community/key-concepts-node.md b/content/en/platform/corda/4.10/community/key-concepts-node.md index ddd957347d7..87835c1b171 100644 --- a/content/en/platform/corda/4.10/community/key-concepts-node.md +++ b/content/en/platform/corda/4.10/community/key-concepts-node.md @@ -35,7 +35,7 @@ title: Nodes A Corda node runs within a Java Virtual Machine (JVM) runtime environment with a [unique network identity]({{< relref "key-concepts-ecosystem.md#node-identities" >}}). JVM runtime environments provide a consistent platform on which you can run and deploy Java applications, such as Corda services and CorDapps. Here is a visualization of the node’s internal architecture: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: diff --git a/content/en/platform/corda/4.10/community/key-concepts-states.md b/content/en/platform/corda/4.10/community/key-concepts-states.md index dcb7bf48c46..3c781a0a4a5 100644 --- a/content/en/platform/corda/4.10/community/key-concepts-states.md +++ b/content/en/platform/corda/4.10/community/key-concepts-states.md @@ -35,7 +35,7 @@ You can use states to represent any type of data, and any kind of fact. For exam This state represents an IOU—an agreement that Alice owes Bob £10: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} In addition to information about the fact, the state contains a reference to the **[contract]({{< relref "key-concepts-contracts.md" >}})**. Contracts govern the evolution of states. @@ -47,14 +47,14 @@ When a fact changes, one of the state's participants creates a new state and mar For example, if Alice pays Bob £5, the state sequence would be: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a **vault**. This is the node's database used to store current and historic states where the node is a participant. For example: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} From each node's point of view, the ledger is the current (non-historic) states where that node is a participant. diff --git a/content/en/platform/corda/4.10/community/key-concepts-tearoffs.md b/content/en/platform/corda/4.10/community/key-concepts-tearoffs.md index 58e2eee74d5..07c310675af 100644 --- a/content/en/platform/corda/4.10/community/key-concepts-tearoffs.md +++ b/content/en/platform/corda/4.10/community/key-concepts-tearoffs.md @@ -39,7 +39,7 @@ Merkle trees split transactions into "leaves". Each leaf contains either an input, an output, a command, or an attachment. The final nested tree structure also contains the other fields of the transaction, such as the time window, the notary, and the required signers. The only component type that requires two trees instead of one is the command, which is split into command data and required signers for visibility purposes. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} Corda uses one nested Merkle tree per component type. A component sub-tree is generated for each component type (for example, inputs, outputs, or attachments). The roots of these sub-trees @@ -65,7 +65,7 @@ obtained belongs to that particular transaction. In this example, assume that only the first command should be visible to the oracle. You must provide guarantees that all the commands the oracle needs to sign are visible to the oracle entity, but no other data. The transaction would be represented in the Merkle tree structure like this: -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} The blue nodes and `H(c2)` are provided to the oracle service, while the black ones are omitted. The oracle needs `H(c2)` so it can compute `H(commandData)` without being to able to see the second command. At the same time, this ensures that `CommandData1` is part of the transaction. All signers are visible as @@ -79,4 +79,4 @@ To send the same transaction to a non-validating notary, hide all components apart from input states, time window, and the notary information. This data is enough for the notary to know which input states to check for double-spending, if the time-window is valid, and if the transaction is being notarized by the correct notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/platform/corda/4.10/community/key-concepts-time-windows.md b/content/en/platform/corda/4.10/community/key-concepts-time-windows.md index cef11cf7b6b..8de46891f6b 100644 --- a/content/en/platform/corda/4.10/community/key-concepts-time-windows.md +++ b/content/en/platform/corda/4.10/community/key-concepts-time-windows.md @@ -46,7 +46,7 @@ trade, or requesting human sign-off. Times in transactions are specified as time *windows*, not absolute times. Time windows can be open-ended, and specify only “before” **or** “after”, or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} When both a before and an after time are included the transaction occurred at some point within that time window. diff --git a/content/en/platform/corda/4.10/community/key-concepts-transactions.md b/content/en/platform/corda/4.10/community/key-concepts-transactions.md index e6b1fed0a54..97f97a0de81 100644 --- a/content/en/platform/corda/4.10/community/key-concepts-transactions.md +++ b/content/en/platform/corda/4.10/community/key-concepts-transactions.md @@ -37,7 +37,7 @@ Every [state]({{< relref "key-concepts-states.md" >}}) is *immutable*: it cannot Here is an example of a transaction with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type. Transactions can: * Include different types of states representing multiple financial instruments, such as cash or bonds. @@ -65,21 +65,21 @@ Input state references consist of: You can see how this works in this example transaction: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} ## Committing transactions to the ledger Initially, a transaction is only a proposal to update the ledger. It represents the future state of the ledger desired by the transaction builders. -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To be committed to the ledger, the transaction must receive signatures from all the *required signers*. Each required signer appends their signature to the transaction to approve the proposal. -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If the transaction gathers the required signatures, it is committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions. @@ -121,7 +121,7 @@ For example, suppose Alice uses $5 cash to pay off $5 of an IOU with Bob. This transaction contains a *settlement command* which reduces the amount outstanding on the IOU, and a *payment command* which changes the ownership of $5 from Alice to Bob. It also has two supporting attachments, and is notarized by `NotaryClusterA` if the notary pool receives it within the specified time window: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -145,7 +145,7 @@ listed in the commands, you get the list of the transaction’s required signers This situation would look like this: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/platform/corda/4.10/community/key-concepts-vault.md b/content/en/platform/corda/4.10/community/key-concepts-vault.md index 9e415b75bda..1a4b4ee78ec 100644 --- a/content/en/platform/corda/4.10/community/key-concepts-vault.md +++ b/content/en/platform/corda/4.10/community/key-concepts-vault.md @@ -45,7 +45,7 @@ The vault supports the management of data in both authoritative **on-ledger** fo This diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} You can see: diff --git a/content/en/platform/corda/4.10/community/network-builder.md b/content/en/platform/corda/4.10/community/network-builder.md index 8144d70e975..2ab460ffff7 100644 --- a/content/en/platform/corda/4.10/community/network-builder.md +++ b/content/en/platform/corda/4.10/community/network-builder.md @@ -21,7 +21,7 @@ title: Corda Network Builder The Corda Network Builder is a tool for building Corda networks for testing purposes. It leverages Docker and containers to abstract the complexity of managing a distributed network away from the user. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} The network you build will either be made up of local `Docker` nodes *or* of nodes spread across Azure containers. For each node a separate Docker image is built based on [corda/community:4.10.6-zulu-openjdk8](https://hub.docker.com/layers/corda/community/4.10.6-zulu-openjdk8/images/sha256-5d79cc924ad6e27bbf9da1706332b1cb6e63df15ff7870241b1e6abb59b7b466). diff --git a/content/en/platform/corda/4.10/community/node-administration.md b/content/en/platform/corda/4.10/community/node-administration.md index c191376a060..b24896a2baf 100644 --- a/content/en/platform/corda/4.10/community/node-administration.md +++ b/content/en/platform/corda/4.10/community/node-administration.md @@ -173,7 +173,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ## Memory usage and tuning diff --git a/content/en/platform/corda/4.10/community/node-database-tables.md b/content/en/platform/corda/4.10/community/node-database-tables.md index 6cf11c9d861..48e125d669f 100644 --- a/content/en/platform/corda/4.10/community/node-database-tables.md +++ b/content/en/platform/corda/4.10/community/node-database-tables.md @@ -49,7 +49,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more here: [The network map]({{< relref "network-map.md" >}}) -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -178,7 +178,7 @@ Read more in [the ledger]({{< relref "key-concepts-ledger.md" >}}) Read more in [Working with attachments]({{< relref "../enterprise/get-started/tutorials/supplementary-tutorials/tutorial-attachments.md" >}}) and [Node services]({{< relref "node-services.md" >}}) -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -469,7 +469,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -498,7 +498,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/platform/corda/4.10/community/permissioning.md b/content/en/platform/corda/4.10/community/permissioning.md index 80442ed467b..38267243e42 100644 --- a/content/en/platform/corda/4.10/community/permissioning.md +++ b/content/en/platform/corda/4.10/community/permissioning.md @@ -52,7 +52,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/platform/corda/4.10/community/upgrading-cordapps.md b/content/en/platform/corda/4.10/community/upgrading-cordapps.md index 6ebcb557d0b..f2695bfd465 100644 --- a/content/en/platform/corda/4.10/community/upgrading-cordapps.md +++ b/content/en/platform/corda/4.10/community/upgrading-cordapps.md @@ -74,7 +74,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="/en/images/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="/en/images/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/platform/corda/4.10/enterprise/api-core-types.md b/content/en/platform/corda/4.10/enterprise/api-core-types.md index ba68e52cab2..35cca17d139 100644 --- a/content/en/platform/corda/4.10/enterprise/api-core-types.md +++ b/content/en/platform/corda/4.10/enterprise/api-core-types.md @@ -66,11 +66,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="./resources/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="./resources/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="./resources/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="./resources/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/platform/corda/4.10/enterprise/apps/bankinabox/user-interface/how-to.md b/content/en/platform/corda/4.10/enterprise/apps/bankinabox/user-interface/how-to.md index 613b641ca12..0577b38acf4 100644 --- a/content/en/platform/corda/4.10/enterprise/apps/bankinabox/user-interface/how-to.md +++ b/content/en/platform/corda/4.10/enterprise/apps/bankinabox/user-interface/how-to.md @@ -70,7 +70,7 @@ Follow these steps to create a new customer profile. When the customer profile is created, they will not have any accounts - you will have to create them. Learn how under [Creating accounts](#create-a-current-account). {{< /note >}} -{{< figure alt="Create customer profile" width=80% zoom="/en/gifs/create-customer-biab-1.0.gif" >}} +{{< figure alt="Create customer profile" width=80% src="/en/gifs/create-customer-biab-1.0.gif" >}} ### Create a Current account @@ -94,7 +94,7 @@ When the customer profile is created, they will not have any accounts - you will 7. When an account is created, it is in **PENDING** status. This must be changed to **ACTIVE** for a customer to be able to interact with and use the account. See [Change an account status](#change-an-account-status) for more information. -{{< figure alt="Create account" width=80% zoom="/en/gifs/create-current-account-biab-1.0.gif" >}} +{{< figure alt="Create account" width=80% src="/en/gifs/create-current-account-biab-1.0.gif" >}} ### Create a Savings account @@ -140,7 +140,7 @@ An account has three statuses: **PENDING**, **ACTIVE**, and **SUSPENDED**. When If the account needs to be suspended, follow the same steps but select **SUSPENDED**. -{{< figure alt="Set account status" width=80% zoom="/en/gifs/set-account-status-biab-1.0.gif" >}} +{{< figure alt="Set account status" width=80% src="/en/gifs/set-account-status-biab-1.0.gif" >}} ### Assign or revoke a user role @@ -163,7 +163,7 @@ To assign a user role, follow these steps: 5. Click **Revoke**. A message will appear indicating that the user role was assigned successfully. -{{< figure alt="Assign role" width=80% zoom="/en/gifs/assign-a-role-biab-1.0.gif" >}} +{{< figure alt="Assign role" width=80% src="/en/gifs/assign-a-role-biab-1.0.gif" >}} #### Revoke a user role @@ -179,7 +179,7 @@ To revoke a user role, follow these steps: 5. Click **Save**. A message will appear indicating that the user role was revoked successfully. -{{< figure alt="Revoke role" width=80% zoom="/en/gifs/revoke-role-biab-1.0.gif" >}} +{{< figure alt="Revoke role" width=80% src="/en/gifs/revoke-role-biab-1.0.gif" >}} ### Issue a loan @@ -195,7 +195,7 @@ Once the account has been set to **ACTIVE**, you will have the ability to issue A loan account is created when a loan has been issued successfully. -{{< figure alt="Issue loan" width=80% zoom="/en/gifs/issue-loan-biab-1.0.gif" >}} +{{< figure alt="Issue loan" width=80% src="/en/gifs/issue-loan-biab-1.0.gif" >}} ### Approve overdrafts @@ -215,7 +215,7 @@ To approve an overdraft, follow these steps. Overdrafts can be approved whether the account is **PENDING**, **ACTIVE**, or **SUSPENDED**. {{< /note >}} -{{< figure alt="Approve overdraft" width=80% zoom="/en/gifs/approve-overdraft-biab-1.0.gif" >}} +{{< figure alt="Approve overdraft" width=80% src="/en/gifs/approve-overdraft-biab-1.0.gif" >}} ### Deposit money to an account @@ -230,7 +230,7 @@ Follow these steps to deposit money to a customer account. 4. Click **Save**. You will receive a message indicating that the deposit was successful. -{{< figure alt="Deposit" width=80% zoom="/en/gifs/deposit-biab-1.0.gif" >}} +{{< figure alt="Deposit" width=80% src="/en/gifs/deposit-biab-1.0.gif" >}} ### Register as a user on Bank in a Box @@ -251,7 +251,7 @@ You must be registered as a **Customer** or **Admin** on Bank in a Box to perfor 5. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update customer profile @@ -284,7 +284,7 @@ An **Admin user** can set an account's **Withdrawal daily limit** or **Transfer 2. Click **Save** when you have entered the desired limits. A message will appear indicating that the limits have been saved successfully. -{{< figure alt="Set withdrawal and transfer limits - admin" width=80% zoom="/en/gifs/set-limits-admin-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - admin" width=80% src="/en/gifs/set-limits-admin-biab-1.0.gif" >}} ## Customer tasks @@ -309,12 +309,12 @@ Follow these steps to create a new intrabank payment. 6. Click **Save**. You will receive a notification indicating that the payment was created successfully. You will also receive notifications indicating any changes in your account balances. -{{< figure alt="Create intrabank payment" width=80% zoom="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} +{{< figure alt="Create intrabank payment" width=80% src="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} After making a payment, you can view the details of this transaction on the Transactions screen. -{{< figure alt="View transaction" width="800" width=80% zoom="/en/gifs/view-transaction-biab-1.0.gif" >}} +{{< figure alt="View transaction" width="800" width=80% src="/en/gifs/view-transaction-biab-1.0.gif" >}} ### Create a recurring payment @@ -338,7 +338,7 @@ Follow these steps to create a recurring payment: 3. You will be taken back to the **Recurring payments screen** where you will receive a message indicating that the recurring payment was created successfully. -{{< figure alt="Recurring payment" width=80% zoom="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} +{{< figure alt="Recurring payment" width=80% src="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} {{< note >}} This payment will not appear on the **Recurring payments screen** until the first iteration has occurred. @@ -367,7 +367,7 @@ You must be registered as a Customer or Admin on Bank in a Box to perform tasks. 7. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update a customer profile @@ -406,4 +406,4 @@ To set these limits as a **Customer**, follow these steps. 4. Click **Save**. You will be taken back to the Account page where you will receive a message indicating that the limits have been updated successfully. -{{< figure alt="Set withdrawal and transfer limits - customer" width=80% zoom="/en/gifs/set-limits-customer-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - customer" width=80% src="/en/gifs/set-limits-customer-biab-1.0.gif" >}} diff --git a/content/en/platform/corda/4.10/enterprise/contract-irs.md b/content/en/platform/corda/4.10/enterprise/contract-irs.md index 2c9c7b9f21b..9e906ea7a21 100644 --- a/content/en/platform/corda/4.10/enterprise/contract-irs.md +++ b/content/en/platform/corda/4.10/enterprise/contract-irs.md @@ -45,7 +45,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="./resources/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="./resources/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/platform/corda/4.10/enterprise/cordapp-advanced-concepts.md b/content/en/platform/corda/4.10/enterprise/cordapp-advanced-concepts.md index 00bdc66cea6..d2d17654a42 100644 --- a/content/en/platform/corda/4.10/enterprise/cordapp-advanced-concepts.md +++ b/content/en/platform/corda/4.10/enterprise/cordapp-advanced-concepts.md @@ -71,7 +71,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="./resources/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="./resources/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/platform/corda/4.10/enterprise/cordapps/api-flows.md b/content/en/platform/corda/4.10/enterprise/cordapps/api-flows.md index 6aa62df3a9e..9934d9e4513 100644 --- a/content/en/platform/corda/4.10/enterprise/cordapps/api-flows.md +++ b/content/en/platform/corda/4.10/enterprise/cordapps/api-flows.md @@ -91,7 +91,7 @@ The `initiator`: You can visualize the work performed by initiator like this: -{{< figure alt="flow overview" width=80% zoom="../resources/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="../resources/flow-overview.png" >}} ## Responder flow class example diff --git a/content/en/platform/corda/4.10/enterprise/cordapps/api-states.md b/content/en/platform/corda/4.10/enterprise/cordapps/api-states.md index f10abb3817d..0b1c227a7af 100644 --- a/content/en/platform/corda/4.10/enterprise/cordapps/api-states.md +++ b/content/en/platform/corda/4.10/enterprise/cordapps/api-states.md @@ -62,7 +62,7 @@ states evolve in a straight line by superseding themselves. You can visualize the hierarchy like this: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/platform/corda/4.10/enterprise/cordapps/cordapp-overview.md b/content/en/platform/corda/4.10/enterprise/cordapps/cordapp-overview.md index b2a4899103a..7aa90e6589a 100644 --- a/content/en/platform/corda/4.10/enterprise/cordapps/cordapp-overview.md +++ b/content/en/platform/corda/4.10/enterprise/cordapps/cordapp-overview.md @@ -31,7 +31,7 @@ CorDapps are: A Corda Distributed Application (CorDapp) solves a specific problem using the Corda framework. CorDapps are stored on Corda nodes and executed on a Corda network. This *distributes* the app, allowing it to run on multiple systems simultaneously—unlike traditional apps, which utilize one dedicated system to achieve an assigned task. CorDapps let nodes communicate with each other to reach agreement on updates to the ledger by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="../resources/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="../resources/node-diagram.png" >}} ## Glossary diff --git a/content/en/platform/corda/4.10/enterprise/cordapps/deterministic-jvm.md b/content/en/platform/corda/4.10/enterprise/cordapps/deterministic-jvm.md index b1deca7f82f..933ab39d3e4 100644 --- a/content/en/platform/corda/4.10/enterprise/cordapps/deterministic-jvm.md +++ b/content/en/platform/corda/4.10/enterprise/cordapps/deterministic-jvm.md @@ -75,7 +75,7 @@ severity `ERROR` will prevent execution. The sandbox has a configuration that applies to the execution of a specific runnable. This configuration, on a higher level, contains a set of rules, definition providers and emitters. -{{< figure alt="djvm overview" width=80% zoom="../resources/djvm-overview.png" >}} +{{< figure alt="djvm overview" width=80% src="../resources/djvm-overview.png" >}} The set of rules is what defines the constraints posed on the runtime environment. A rule can act on three different levels, namely on a type-, member- or instruction-level. The set of rules get processed and validated by the `RuleValidator` prior to execution. diff --git a/content/en/platform/corda/4.10/enterprise/cordapps/upgrading-cordapps.md b/content/en/platform/corda/4.10/enterprise/cordapps/upgrading-cordapps.md index 0e928f3b165..0483ed6f730 100644 --- a/content/en/platform/corda/4.10/enterprise/cordapps/upgrading-cordapps.md +++ b/content/en/platform/corda/4.10/enterprise/cordapps/upgrading-cordapps.md @@ -68,7 +68,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="../resources/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="../resources/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/platform/corda/4.10/enterprise/financial-model.md b/content/en/platform/corda/4.10/enterprise/financial-model.md index 1254db0a278..87407f504b7 100644 --- a/content/en/platform/corda/4.10/enterprise/financial-model.md +++ b/content/en/platform/corda/4.10/enterprise/financial-model.md @@ -92,6 +92,6 @@ countable (in cents), barrels of oil are fungible and countable (oil from two sm container), shares of the same class in a specific company are fungible and countable, and so on. This diagram illustrates the complete contract state hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Corda provides two packages: a core library and a finance model-specific library. You can re-use or extend the finance types directly, or write your own by extending the base types from the core library. diff --git a/content/en/platform/corda/4.10/enterprise/health-survey.md b/content/en/platform/corda/4.10/enterprise/health-survey.md index 992c0ada181..0a9aeeccabe 100644 --- a/content/en/platform/corda/4.10/enterprise/health-survey.md +++ b/content/en/platform/corda/4.10/enterprise/health-survey.md @@ -116,7 +116,7 @@ The Corda Health Survey currently does not support testing RPC communication if The tool generates the archive of the collected files in the same directory it is ran in. The names are in the format: `report-date-time.zip` -{{< figure alt="health survey photo" width=80% zoom="resources/health-survey-photo.png" >}} +{{< figure alt="health survey photo" width=80% src="resources/health-survey-photo.png" >}} ## Deployment health check diff --git a/content/en/platform/corda/4.10/enterprise/key-concepts-consensus.md b/content/en/platform/corda/4.10/enterprise/key-concepts-consensus.md index c8597a30570..ef7e3f3825f 100644 --- a/content/en/platform/corda/4.10/enterprise/key-concepts-consensus.md +++ b/content/en/platform/corda/4.10/enterprise/key-concepts-consensus.md @@ -48,7 +48,7 @@ transferring a treasury bond, the bond transfer is only valid if: Walking the chain for this transaction would look like this: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a node may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer. The @@ -67,7 +67,7 @@ proposals: Both transactions will achieve validity consensus, yet Alice has managed to “double-spend” her USD to get double the amount of GBP and EUR: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/platform/corda/4.10/enterprise/key-concepts-contracts.md b/content/en/platform/corda/4.10/enterprise/key-concepts-contracts.md index 3d52d932ee1..a986e999efc 100644 --- a/content/en/platform/corda/4.10/enterprise/key-concepts-contracts.md +++ b/content/en/platform/corda/4.10/enterprise/key-concepts-contracts.md @@ -55,7 +55,7 @@ transaction gathers all the required signatures, it can't be executed unless it Each transaction [state]({{< relref "key-concepts-states.md" >}}) specifies a *contract type*. The contract specified takes the transaction as input, and determines if the transaction is valid based on the contract's internal rules. The contract must evaluate every input state and every output state. -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code can: * Check the number of inputs, outputs, commands, or attachments. diff --git a/content/en/platform/corda/4.10/enterprise/key-concepts-ecosystem.md b/content/en/platform/corda/4.10/enterprise/key-concepts-ecosystem.md index 1071b2c73e7..23230a89e37 100644 --- a/content/en/platform/corda/4.10/enterprise/key-concepts-ecosystem.md +++ b/content/en/platform/corda/4.10/enterprise/key-concepts-ecosystem.md @@ -32,7 +32,7 @@ title: Networks, identity, and discovery ## What is a network? On Corda, people and business interact by communicating over a peer-to-peer network of [Corda nodes]({{< relref "key-concepts-node.md" >}}). Each node represents a legal entity running Corda and one or more Corda distributed applications, known as [CorDapps]({{< relref "cordapps/cordapp-overview.md" >}}). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} Corda is different from other distributed ledgers because all communication between nodes is point-to-point, and only shared on a need-to-know basis. It is also encrypted using transport-layer security. There are *no global broadcasts* to all parties on a network, but all of the nodes in a network can send messages directly to other nodes. If the recipient is offline, the message waits in an outbound queue until they are online again—just like an email. ## Join a network diff --git a/content/en/platform/corda/4.10/enterprise/key-concepts-flows.md b/content/en/platform/corda/4.10/enterprise/key-concepts-flows.md index e3f1a730fe8..a2c5c4b5649 100644 --- a/content/en/platform/corda/4.10/enterprise/key-concepts-flows.md +++ b/content/en/platform/corda/4.10/enterprise/key-concepts-flows.md @@ -35,7 +35,7 @@ must specify what information needs to be sent, to which counterparties, and in Here is a visualisation of Alice and Bob agreeing a ledger update using this process: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -44,7 +44,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is a diagram showing the flow's steps used between Alice and Bob to perform the ledger update: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/platform/corda/4.10/enterprise/key-concepts-ledger.md b/content/en/platform/corda/4.10/enterprise/key-concepts-ledger.md index fc837938dc4..4feac477a3b 100644 --- a/content/en/platform/corda/4.10/enterprise/key-concepts-ledger.md +++ b/content/en/platform/corda/4.10/enterprise/key-concepts-ledger.md @@ -39,7 +39,7 @@ loan are Alice and Bob, then they are the only nodes that ever see or store this This diagram shows a network with five nodes (Alice, Bob, Carl, Demi, and Ed). Each numbered circle on an intersection represents a fact shared between two or more nodes: -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} In the diagram, facts 1 and 7 are known by both Alice and Bob. Alice only shares facts with Bob, Alice doesn't share any facts with Carl, Demi, or Ed. @@ -56,7 +56,7 @@ each node maintains its own vault, which contains all of its known facts. You can think of a vault as being a database or simple table. In this diagram, facts 1 and 7 appear on both Alice's vault and Bob's vault, and are therefore shared facts: -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} When multiple nodes on a network share an evolving fact, the changes to the fact update at the same time in each node's vault. This means that Alice and Bob will both see an *identical version* of shared facts 1 and 7. diff --git a/content/en/platform/corda/4.10/enterprise/key-concepts-node.md b/content/en/platform/corda/4.10/enterprise/key-concepts-node.md index 812f95dcd1b..eadffea14b3 100644 --- a/content/en/platform/corda/4.10/enterprise/key-concepts-node.md +++ b/content/en/platform/corda/4.10/enterprise/key-concepts-node.md @@ -35,7 +35,7 @@ title: Nodes A Corda node runs within a Java Virtual Machine (JVM) runtime environment with a [unique network identity]({{< relref "key-concepts-ecosystem.md#node-identities" >}}). JVM runtime environments provide a consistent platform on which you can run and deploy Java applications, such as Corda services and CorDapps. Here is a visualization of the node’s internal architecture: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: diff --git a/content/en/platform/corda/4.10/enterprise/key-concepts-states.md b/content/en/platform/corda/4.10/enterprise/key-concepts-states.md index 5efa8dee876..c42fb71bd50 100644 --- a/content/en/platform/corda/4.10/enterprise/key-concepts-states.md +++ b/content/en/platform/corda/4.10/enterprise/key-concepts-states.md @@ -35,7 +35,7 @@ You can use states to represent any type of data, and any kind of fact. For exam This state represents an IOU—an agreement that Alice owes Bob £10: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} In addition to information about the fact, the state contains a reference to the *[contract]({{< relref "key-concepts-contracts.md" >}})*. Contracts govern the evolution of states. @@ -47,14 +47,14 @@ When a fact changes, one of the state's participants creates a new state and mar For example, if Alice pays Bob £5, the state sequence would be: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a *vault*. This is the node's database used to store current and historic states where the node is a participant. For example: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} From each node's point of view, the ledger is the current (non-historic) states where that node is a participant. diff --git a/content/en/platform/corda/4.10/enterprise/key-concepts-tearoffs.md b/content/en/platform/corda/4.10/enterprise/key-concepts-tearoffs.md index 806785f9c67..e26b0c4607d 100644 --- a/content/en/platform/corda/4.10/enterprise/key-concepts-tearoffs.md +++ b/content/en/platform/corda/4.10/enterprise/key-concepts-tearoffs.md @@ -39,7 +39,7 @@ Merkle trees split transactions into "leaves". Each leaf contains either an input, an output, a command, or an attachment. The final nested tree structure also contains the other fields of the transaction, such as the time window, the notary, and the required signers. The only component type that requires two trees instead of one is the command, which is split into command data and required signers for visibility purposes. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} Corda uses one nested Merkle tree per component type. A component sub-tree is generated for each component type (for example, inputs, outputs, or attachments). The roots of these sub-trees @@ -65,7 +65,7 @@ obtained belongs to that particular transaction. In this example, assume that only the first command should be visible to the oracle. You must provide guarantees that all the commands the oracle needs to sign are visible to the oracle entity, but no other data. The transaction would be represented in the Merkle tree structure like this: -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} The blue nodes and `H(c2)` are provided to the oracle service, while the black ones are omitted. The oracle needs `H(c2)` so it can compute `H(commandData)` without being to able to see the second command. At the same time, this ensures that `CommandData1` is part of the transaction. All signers are visible as @@ -79,4 +79,4 @@ To send the same transaction to a non-validating notary, hide all components apart from input states, time window, and the notary information. This data is enough for the notary to know which input states to check for double-spending, if the time-window is valid, and if the transaction is being notarized by the correct notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/platform/corda/4.10/enterprise/key-concepts-time-windows.md b/content/en/platform/corda/4.10/enterprise/key-concepts-time-windows.md index 4134494dc82..d3eb03ed616 100644 --- a/content/en/platform/corda/4.10/enterprise/key-concepts-time-windows.md +++ b/content/en/platform/corda/4.10/enterprise/key-concepts-time-windows.md @@ -46,7 +46,7 @@ trade, or requesting human sign-off. Times in transactions are specified as time *windows*, not absolute times. Time windows can be open-ended, and specify only “before” **or** “after”, or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} When both a before and an after time are included the transaction occurred at some point within that time window. diff --git a/content/en/platform/corda/4.10/enterprise/key-concepts-transactions.md b/content/en/platform/corda/4.10/enterprise/key-concepts-transactions.md index 16112f3a9f8..fdf7eb595cf 100644 --- a/content/en/platform/corda/4.10/enterprise/key-concepts-transactions.md +++ b/content/en/platform/corda/4.10/enterprise/key-concepts-transactions.md @@ -37,7 +37,7 @@ Every [state]({{< relref "key-concepts-states.md" >}}) is *immutable*—it can't Here is an example of a transaction with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type. Transactions can: * Include different types of states representing multiple financial instruments, such as cash or bonds. @@ -65,21 +65,21 @@ Input state references consist of: You can see how this works in this example transaction: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} ## Committing transactions to the ledger Initially, a transaction is only a proposal to update the ledger. It represents the future state of the ledger desired by the transaction builders. -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To be committed to the ledger, the transaction must receive signatures from all the *required signers*. Each required signer appends their signature to the transaction to approve the proposal. -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If the transaction gathers the required signatures, it is committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions. @@ -121,7 +121,7 @@ For example, suppose Alice uses $5 cash to pay off $5 of an IOU with Bob. This transaction contains a *settlement command* which reduces the amount outstanding on the IOU, and a *payment command* which changes the ownership of $5 from Alice to Bob. It also has two supporting attachments, and is notarized by `NotaryClusterA` if the notary pool receives it within the specified time window: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -145,7 +145,7 @@ listed in the commands, you get the list of the transaction’s required signers This situation would look like this: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/platform/corda/4.10/enterprise/key-concepts-vault.md b/content/en/platform/corda/4.10/enterprise/key-concepts-vault.md index 1959d21a0fc..fb341cb514c 100644 --- a/content/en/platform/corda/4.10/enterprise/key-concepts-vault.md +++ b/content/en/platform/corda/4.10/enterprise/key-concepts-vault.md @@ -46,7 +46,7 @@ The vault supports the management of data in both authoritative **on-ledger** fo This diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} You can see: diff --git a/content/en/platform/corda/4.10/enterprise/network-builder.md b/content/en/platform/corda/4.10/enterprise/network-builder.md index 5d3219cbe04..08bc3e03da1 100644 --- a/content/en/platform/corda/4.10/enterprise/network-builder.md +++ b/content/en/platform/corda/4.10/enterprise/network-builder.md @@ -21,7 +21,7 @@ title: Corda Network Builder The Corda Network Builder is a tool for building Corda networks for testing purposes. It leverages Docker and containers to abstract the complexity of managing a distributed network away from the user. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} The network you build will either be made up of local `Docker` nodes *or* of nodes spread across Azure containers. For each node a separate Docker image is built based on [corda/corda-enterprise:4.10.6-zulu-openjdk8-alpine](https://hub.docker.com/layers/corda/corda-enterprise/4.10.6-zulu-openjdk8-alpine/images/sha256-d80eabb74783c3fa2072e9750fcba6a9dc66b0696b6b0d867f6390bdbd845007). diff --git a/content/en/platform/corda/4.10/enterprise/network/cipher-suites.md b/content/en/platform/corda/4.10/enterprise/network/cipher-suites.md index 89f71ae1403..bc2692d293c 100644 --- a/content/en/platform/corda/4.10/enterprise/network/cipher-suites.md +++ b/content/en/platform/corda/4.10/enterprise/network/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates]({{< relref "permissioning.md" >}})): -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/platform/corda/4.10/enterprise/network/permissioning.md b/content/en/platform/corda/4.10/enterprise/network/permissioning.md index 5b9638a40f8..84d60f446bf 100644 --- a/content/en/platform/corda/4.10/enterprise/network/permissioning.md +++ b/content/en/platform/corda/4.10/enterprise/network/permissioning.md @@ -42,7 +42,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/platform/corda/4.10/enterprise/node/collaborative-recovery/deployment-and-operations.md b/content/en/platform/corda/4.10/enterprise/node/collaborative-recovery/deployment-and-operations.md index bf7a57530cd..27bba6efc90 100644 --- a/content/en/platform/corda/4.10/enterprise/node/collaborative-recovery/deployment-and-operations.md +++ b/content/en/platform/corda/4.10/enterprise/node/collaborative-recovery/deployment-and-operations.md @@ -90,7 +90,7 @@ The space complexities are outlined below: You can see a suggested high-level, disaster recovery setup in the diagram below. -{{< figure alt="Suggested Disaster Recovery Setup" width=80% zoom="../../resources/collaborative-recovery/dr-setup.png" >}} +{{< figure alt="Suggested Disaster Recovery Setup" width=80% src="../../resources/collaborative-recovery/dr-setup.png" >}} The exact setup you choose is likely to be influenced by your organisation and business requirements, but the key points are: diff --git a/content/en/platform/corda/4.10/enterprise/node/collaborative-recovery/introduction-cr.md b/content/en/platform/corda/4.10/enterprise/node/collaborative-recovery/introduction-cr.md index a1615c5df88..bcfc32a6541 100644 --- a/content/en/platform/corda/4.10/enterprise/node/collaborative-recovery/introduction-cr.md +++ b/content/en/platform/corda/4.10/enterprise/node/collaborative-recovery/introduction-cr.md @@ -153,7 +153,7 @@ inbound / outbound reconciliations and also supports different throttling techni A high-level, peer-to-peer reconciliation flow is depicted in the diagram below. **LedgerSync** can run multiple reconciliations concurrently, up to the limit configured by the user. -{{< figure alt="Peer-to-Peer Reconciliation Flow" width=80% zoom="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} +{{< figure alt="Peer-to-Peer Reconciliation Flow" width=80% src="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} ### LedgerRecover @@ -176,7 +176,7 @@ supports different types of throttling to prevent accidental abuse of the functi A high-level, peer-to-peer automatic recovery flow is depicted in the diagram below. -{{< figure alt="Peer-to-Peer Automatic Recovery Flow" width=80% zoom="../../resources/collaborative-recovery/automatic-ledger-recover-flow.png" >}} +{{< figure alt="Peer-to-Peer Automatic Recovery Flow" width=80% src="../../resources/collaborative-recovery/automatic-ledger-recover-flow.png" >}} {{< attention >}} Even though the recovery flow contains the word "automatic" in its name, it can only be started manually. @@ -195,7 +195,7 @@ the import has been stopped halfway through. A high-level, peer-to-peer manual recovery flow is depicted in the diagram below. -{{< figure alt="Peer-to-Peer Manual Recovery Flow" width=80% zoom="../../resources/collaborative-recovery/manual-ledger-recover-flow.png" >}} +{{< figure alt="Peer-to-Peer Manual Recovery Flow" width=80% src="../../resources/collaborative-recovery/manual-ledger-recover-flow.png" >}} ### Supported disaster recovery scenarios diff --git a/content/en/platform/corda/4.10/enterprise/node/collaborative-recovery/ledger-sync.md b/content/en/platform/corda/4.10/enterprise/node/collaborative-recovery/ledger-sync.md index 2f4db9cc3b9..2b214d1cd2f 100644 --- a/content/en/platform/corda/4.10/enterprise/node/collaborative-recovery/ledger-sync.md +++ b/content/en/platform/corda/4.10/enterprise/node/collaborative-recovery/ledger-sync.md @@ -28,7 +28,7 @@ All reconciliations are added to a bounded execution pool, which is configurable This means the node that requested the reconciliation will be notified if the responding node has transactions that the requesting node does not. The responding node will not be notified if the requesting node has transactions that the responding node does not. -{{< figure alt="LedgerSync Flow" width=80% zoom="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} +{{< figure alt="LedgerSync Flow" width=80% src="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} ### Integration with Archiving diff --git a/content/en/platform/corda/4.10/enterprise/node/component-topology.md b/content/en/platform/corda/4.10/enterprise/node/component-topology.md index 8dcf6626ed0..9a7b7954556 100644 --- a/content/en/platform/corda/4.10/enterprise/node/component-topology.md +++ b/content/en/platform/corda/4.10/enterprise/node/component-topology.md @@ -33,7 +33,7 @@ The key node components and services are: * The Corda firewall -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" figcaption="Node internal architecture.">}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" figcaption="Node internal architecture.">}} ### CorDapps @@ -83,14 +83,14 @@ Nodes communicate with other nodes using asynchronous AMQP/TLS 1.2 protocols. HT Nodes communicate with client applications using RPC calls. -{{< figure alt="overview" width=80% zoom="../resources/overview.png" >}} +{{< figure alt="overview" width=80% src="../resources/overview.png" >}} ## Typical node deployments In most cases, nodes are deployed with this architecture: -{{< figure alt="nodebridgefloat nbrs" width=80% zoom="../resources/nodebridgefloat_nbrs.png" figcaption="A typical node deployment.">}} +{{< figure alt="nodebridgefloat nbrs" width=80% src="../resources/nodebridgefloat_nbrs.png" figcaption="A typical node deployment.">}} Most production deployments of Corda Enterprise include nodes, vaults, and firewalls. diff --git a/content/en/platform/corda/4.10/enterprise/node/corda-firewall-component.md b/content/en/platform/corda/4.10/enterprise/node/corda-firewall-component.md index d1ba1a1cfb2..e54d3c8f809 100644 --- a/content/en/platform/corda/4.10/enterprise/node/corda-firewall-component.md +++ b/content/en/platform/corda/4.10/enterprise/node/corda-firewall-component.md @@ -140,7 +140,7 @@ Artemis with the node as TLS endpoint and to have the outgoing packets use the i Typically this should only be used for easy development, or for organisations evaluating on Open Source Corda, where this is the only available option: -{{< figure alt="node embedded bridge" width=80% zoom="/en/images/node_embedded_bridge.png" >}} +{{< figure alt="node embedded bridge" width=80% src="/en/images/node_embedded_bridge.png" >}} ### Node + Combined Bridge/Float (no DMZ) @@ -170,7 +170,7 @@ Then configure an all-in-one bridge to point at this node’s `messagingServerAd {{< /note >}} -{{< figure alt="simple bridge" width=80% zoom="/en/images/simple_bridge.png" >}} +{{< figure alt="simple bridge" width=80% src="/en/images/simple_bridge.png" >}} #### node.conf @@ -238,7 +238,7 @@ key, the tunnel link should use a private set of link specific keys and certific dynamically with the official TLS key when activated via the tunnel and this key will never be stored in the DMZ: {{< /note >}} -{{< figure alt="node bridge float" width=80% zoom="/en/images/node_bridge_float.png" >}} +{{< figure alt="node bridge float" width=80% src="/en/images/node_bridge_float.png" >}} #### node.conf @@ -326,7 +326,7 @@ Some organisations require dynamic outgoing connections to operate via a SOCKS p by adding extra information to the `outboundConfig` section of the bridge process. A simplified example deployment is shown here to highlight the option: -{{< figure alt="socks proxy" width=80% zoom="/en/images/socks_proxy.png" >}} +{{< figure alt="socks proxy" width=80% src="/en/images/socks_proxy.png" >}} #### node.conf @@ -426,7 +426,7 @@ Highlighted in the diagram is the addition of the `haConfig` section to point at addresses in the `alternateArtemisAddresses` to allow node failover and in the `floatAddresses` to point at a pool of DMZ float processes. -{{< figure alt="ha nodes" width=80% zoom="/en/images/ha_nodes.png" >}} +{{< figure alt="ha nodes" width=80% src="/en/images/ha_nodes.png" >}} #### node.conf @@ -563,7 +563,7 @@ It is possible to allow two or more Corda nodes (HA and/or non-HA) handle outgoi an external Artemis messaging broker which can be easily configured using the ha-tool. For more information, please see HA Utilities. While this example is the simplest deployment possible with a shared bridge, any other configuration previously presented can be created. -{{< figure alt="multiple nodes no ha" width=80% zoom="/en/images/multiple_nodes_no_ha.png" >}} +{{< figure alt="multiple nodes no ha" width=80% src="/en/images/multiple_nodes_no_ha.png" >}} #### bank-a-node.conf diff --git a/content/en/platform/corda/4.10/enterprise/node/corda-firewall-configuration-file.md b/content/en/platform/corda/4.10/enterprise/node/corda-firewall-configuration-file.md index 18f815647d7..313435c8fef 100644 --- a/content/en/platform/corda/4.10/enterprise/node/corda-firewall-configuration-file.md +++ b/content/en/platform/corda/4.10/enterprise/node/corda-firewall-configuration-file.md @@ -132,14 +132,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -152,7 +152,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/platform/corda/4.10/enterprise/node/deploy/env-prod-test.md b/content/en/platform/corda/4.10/enterprise/node/deploy/env-prod-test.md index 4f9a1fd1ec3..8926f4ef4e3 100644 --- a/content/en/platform/corda/4.10/enterprise/node/deploy/env-prod-test.md +++ b/content/en/platform/corda/4.10/enterprise/node/deploy/env-prod-test.md @@ -33,12 +33,12 @@ There are alternative approaches to how these components are deployed. For the p When deploying Corda Enterprise in a testing environment the Node, Bridge, and Float components should be deployed in a non-HA configuration as shown in the following diagram. -{{< figure alt="nonha" width=80% zoom="../../resources/nonha.png" >}} +{{< figure alt="nonha" width=80% src="../../resources/nonha.png" >}} When deploying Corda Enterprise in a production environment, the Node, Bridge, and Float components should be deployed in a high-availability configuration. -{{< figure alt="ha" width=80% zoom="../../resources/ha.png" >}} +{{< figure alt="ha" width=80% src="../../resources/ha.png" >}} ### Deployment details @@ -204,7 +204,7 @@ This is a sample `node.conf` which details a configuration connecting to a Corda In a bank environment there will typically be several layers of security protecting the firms data. -{{< figure alt="cordarch" width=80% zoom="../../resources/cordarch.png" >}} +{{< figure alt="cordarch" width=80% src="../../resources/cordarch.png" >}} *Network Authentication* @@ -218,7 +218,7 @@ In a bank environment there will typically be several layers of security protect * Corda PKI Authentication issued by Corda Network can link the Node and Bridge i.e. the red keys indicated below truststore and sslkeystore * Local PKI Authentication issued by separate CA will link the Bridge and Float i.e the purple keys indicated below trust and Bridge. -{{< figure alt="firewallpki" width=80% zoom="../../resources/firewallpki.png" >}} +{{< figure alt="firewallpki" width=80% src="../../resources/firewallpki.png" >}} The key thing is to look at this from the perspective of a bank implementing these Corda and Local PKI keys. @@ -373,7 +373,7 @@ Administrative logins with the Corda node happen via ssh whose port is configure The following image may be helpful in ensuring alignment between the Node, Bridge and Float configuration files. -{{< figure alt="CordaFirewallConfigAlign" width=80% zoom="../../resources/CordaFirewallConfigAlign.png" >}} +{{< figure alt="CordaFirewallConfigAlign" width=80% src="../../resources/CordaFirewallConfigAlign.png" >}} {{< note >}} **p2pAddress** reflects the **publicly accessible address**, which may or may not be the Float inboundConfig.listeningAddress. If there is an internet firewall configured in front of the Float then ask the Network Administrator for the public address that routes to the Float’s **listeningAddress**, and use that public address for your **p2pAddress**. diff --git a/content/en/platform/corda/4.10/enterprise/node/deploy/hot-cold-deployment.md b/content/en/platform/corda/4.10/enterprise/node/deploy/hot-cold-deployment.md index 966ae3307e9..9ef0fa90c98 100644 --- a/content/en/platform/corda/4.10/enterprise/node/deploy/hot-cold-deployment.md +++ b/content/en/platform/corda/4.10/enterprise/node/deploy/hot-cold-deployment.md @@ -36,7 +36,7 @@ resources for both **Microsoft Azure** and **Amazon Web Services**. The image be result from following the guide. There will be two Corda Enterprise nodes, one active and the other inactive. Each node will represent the same legal identity inside the Corda network. Both will share a database and a network file system. -{{< figure alt="hot cold" width=80% zoom="../../resources/hot-cold.png" >}} +{{< figure alt="hot cold" width=80% src="../../resources/hot-cold.png" >}} ## Configuring the load balancer diff --git a/content/en/platform/corda/4.10/enterprise/node/operating/node-administration.md b/content/en/platform/corda/4.10/enterprise/node/operating/node-administration.md index 04a23d035b1..3a3958b2471 100644 --- a/content/en/platform/corda/4.10/enterprise/node/operating/node-administration.md +++ b/content/en/platform/corda/4.10/enterprise/node/operating/node-administration.md @@ -245,7 +245,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ### Monitoring via Graphite diff --git a/content/en/platform/corda/4.10/enterprise/node/operating/node-database-tables.md b/content/en/platform/corda/4.10/enterprise/node/operating/node-database-tables.md index e361be564c6..543cea2a562 100644 --- a/content/en/platform/corda/4.10/enterprise/node/operating/node-database-tables.md +++ b/content/en/platform/corda/4.10/enterprise/node/operating/node-database-tables.md @@ -42,7 +42,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more in [Network map]({{< relref "../../network/network-map.md" >}}). -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -170,7 +170,7 @@ Read more in [Ledger]({{< relref "../../key-concepts-ledger.md" >}}). ### Attachments Read more in [Working with attachments]({{< relref "../../get-started/tutorials/supplementary-tutorials/tutorial-attachments.md" >}}) and [Node services]({{< relref "../../node-services.md" >}}). -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -466,7 +466,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -495,7 +495,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/platform/corda/4.10/enterprise/node/pki-guide.md b/content/en/platform/corda/4.10/enterprise/node/pki-guide.md index 11344340fbd..ee482991049 100644 --- a/content/en/platform/corda/4.10/enterprise/node/pki-guide.md +++ b/content/en/platform/corda/4.10/enterprise/node/pki-guide.md @@ -54,7 +54,7 @@ as they root to the same certificate. Other than that, Corda nodes stay agnostic to the certificate hierarchy (in particular the depth of the certificate hierarchy tree). -{{< figure alt="hierarchy agnostic" width=80% zoom="../resources/hierarchy-agnostic.png" >}} +{{< figure alt="hierarchy agnostic" width=80% src="../resources/hierarchy-agnostic.png" >}} At the time of writing this document, the Corda Network assumes the certificate hierarchy that can be found in the [Certificate hierarchy guide]({{< relref "../network/permissioning.md#certificate-hierarchy" >}}). @@ -69,7 +69,7 @@ The network operator is responsible for certificate issuance and maintenance for at the Identity Manager and Network Map certificates. The rest of the certificate chain (i.e. every certificate below the Identity Manager certificate) falls into node operator responsibility. -{{< figure alt="tls hierarchy" width=80% zoom="../resources/tls-hierarchy.png" >}} +{{< figure alt="tls hierarchy" width=80% src="../resources/tls-hierarchy.png" >}} The certificate revocation list verification applies to the entire chain. This means that every certificate in the chain is going to be validated against the corresponding certificate revocation list during the SSL handshake. Consequently, this means that a node operator is expected to provide and maintain the certificate revocation list for the Node CA. @@ -87,7 +87,7 @@ During the certificate revocation list validation process the trust store is con As an example, let us consider the following certificate hierarchy: -{{< figure alt="example hierarchy" width=80% zoom="../resources/example-hierarchy.png" >}} +{{< figure alt="example hierarchy" width=80% src="../resources/example-hierarchy.png" >}} The certificate hierarchy presented above is currently (as of the time of writing this document) used in the Corda Network. It follows practices applicable for certificate authorities providing a balance between security and simplicity of usage. In this scenario, a network operator wants to create a CA hierarchy where the self-signed Root CA issues a certificate for the Subordinate CA which in turn issues diff --git a/content/en/platform/corda/4.10/enterprise/notary-healthcheck.md b/content/en/platform/corda/4.10/enterprise/notary-healthcheck.md index 6ff757d17ab..9bf10a9f816 100644 --- a/content/en/platform/corda/4.10/enterprise/notary-healthcheck.md +++ b/content/en/platform/corda/4.10/enterprise/notary-healthcheck.md @@ -171,4 +171,4 @@ monitor notary health via a dashboard or hook up an alerter. As an example, this view on a failing notary check. Note the metrics for *success*, *fail*, *inflight*, and *maxinflightTime* for the notary service and the cluster members on the left hand side. -{{< figure alt="hawtio healthcheck" width=80% zoom="./resources/hawtio-healthcheck.png" >}} +{{< figure alt="hawtio healthcheck" width=80% src="./resources/hawtio-healthcheck.png" >}} diff --git a/content/en/platform/corda/4.10/enterprise/notary/backup-restore.md b/content/en/platform/corda/4.10/enterprise/notary/backup-restore.md index c8d6615a239..3c9d09c2bf2 100644 --- a/content/en/platform/corda/4.10/enterprise/notary/backup-restore.md +++ b/content/en/platform/corda/4.10/enterprise/notary/backup-restore.md @@ -29,7 +29,7 @@ Additionally, it is critical to have a backup of the Notary Service identity pri The following diagram highlights in blue which storage components should be backed up. -{{< figure alt="storage components" width=80% zoom="../resources/storage-components.png" >}} +{{< figure alt="storage components" width=80% src="../resources/storage-components.png" >}} Note that for regular nodes it is very important to back up the Messaging Broker (Artemis) folder and the local Database, but for HA notary nodes that are purely used for notarisation purposes that is not needed. To summarise: diff --git a/content/en/platform/corda/4.10/enterprise/notary/ha-notary-service-overview.md b/content/en/platform/corda/4.10/enterprise/notary/ha-notary-service-overview.md index fbaed28f0c8..df816d0f662 100644 --- a/content/en/platform/corda/4.10/enterprise/notary/ha-notary-service-overview.md +++ b/content/en/platform/corda/4.10/enterprise/notary/ha-notary-service-overview.md @@ -60,7 +60,7 @@ database to store its node state (e.g. its identity information). We can visualise this set-up as follows, with the regular Corda nodes in green, the Corda notary worker nodes in red, and the standard node databases and notary state database replicas in blue. -{{< figure alt="ha notary overview2" width=80% zoom="../resources/ha-notary-overview2.png" >}} +{{< figure alt="ha notary overview2" width=80% src="../resources/ha-notary-overview2.png" >}} Nodes requesting notarisation from a highly-available notary will connect to the notary workers in round-robin fashion. Provided there are multiple notary workers and the notary state database is configured to be highly-available, the overall notary service @@ -73,7 +73,7 @@ In production, R3 recommends running five or more replicas in the notary state d If desired, you can choose to run each database server and its Corda notary worker on the same machine: -{{< figure alt="ha notary colocated" width=80% zoom="../resources/ha-notary-colocated.png" >}} +{{< figure alt="ha notary colocated" width=80% src="../resources/ha-notary-colocated.png" >}} ## Notary configuration diff --git a/content/en/platform/corda/4.10/enterprise/notary/hsm-support.md b/content/en/platform/corda/4.10/enterprise/notary/hsm-support.md index a730cbb29af..a0b782b44b9 100644 --- a/content/en/platform/corda/4.10/enterprise/notary/hsm-support.md +++ b/content/en/platform/corda/4.10/enterprise/notary/hsm-support.md @@ -14,7 +14,7 @@ weight: 3 ## Overview -{{< figure alt="hsm support" width=80% zoom="../resources/hsm-support.png" >}} +{{< figure alt="hsm support" width=80% src="../resources/hsm-support.png" >}} Two notary workers and their relevant cryptographic keys used for P2P messaging and transaction signing. The red rectangles represent the Corda notary worker services. The distinct identity keys are represented by rectangles in green and yellow and the shared key of the notary service identity is drawn in blue. Their cryptographic keys are held in a single HSM. diff --git a/content/en/platform/corda/4.10/enterprise/operations/deployment/firewall-deployment.md b/content/en/platform/corda/4.10/enterprise/operations/deployment/firewall-deployment.md index b549db723f9..4db17ab0817 100644 --- a/content/en/platform/corda/4.10/enterprise/operations/deployment/firewall-deployment.md +++ b/content/en/platform/corda/4.10/enterprise/operations/deployment/firewall-deployment.md @@ -129,14 +129,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -149,7 +149,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/platform/corda/4.10/enterprise/performance-testing/introduction.md b/content/en/platform/corda/4.10/enterprise/performance-testing/introduction.md index c427f560bc6..6ecee72cad8 100644 --- a/content/en/platform/corda/4.10/enterprise/performance-testing/introduction.md +++ b/content/en/platform/corda/4.10/enterprise/performance-testing/introduction.md @@ -110,7 +110,7 @@ The driving app sits outside the network and connects to the JMeter servers thro measuring the throughput of a node, the test definition instructs all JMeter servers to open RPC connections to one node, thus saturating the RPC handler and driving the node as hard as possible. The test might invoke a flow that can be completed locally (for example, cash issuance) or it might require exchanging P2P messages with other nodes (for example, cash payment). -{{< figure alt="jmeter network overview" width=80% zoom="../resources/jmeter-network-overview.png" >}} +{{< figure alt="jmeter network overview" width=80% src="../resources/jmeter-network-overview.png" >}} ## Performance tests diff --git a/content/en/platform/corda/4.10/enterprise/performance-testing/jmeter-samplers.md b/content/en/platform/corda/4.10/enterprise/performance-testing/jmeter-samplers.md index 4a34783491f..4c693f0a5b9 100644 --- a/content/en/platform/corda/4.10/enterprise/performance-testing/jmeter-samplers.md +++ b/content/en/platform/corda/4.10/enterprise/performance-testing/jmeter-samplers.md @@ -66,7 +66,7 @@ server, not the client machine. * `minimumNodePlatformVersion`: the minimum platform version that the JMeter client will require from the Corda nodes. It defaults to 4, which can be used to test with Corda 4.0 nodes or later. * `username`: the RPC user name of the Corda node. * `password`: the RPC password of the Corda node. -{{< figure alt="empty flow sampler" width=80% zoom="../resources/empty-flow-sampler.png" >}} +{{< figure alt="empty flow sampler" width=80% src="../resources/empty-flow-sampler.png" >}} * `CashIssueSampler`: this sampler client has the class name `com.r3.corda.jmeter.CashIssueSampler` and starts the flow `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueFlow`. This flow self-issues 1.1 billion cash tokens on the node it is running on, and stores it in the vault. In addition to the common properties described for `EmptyFlowSampler` above, this sampler client also requires: * `notaryName`: the X500 name of the notary that is acceptable to transfer cash tokens issued via this sampler. Issuing tokens does not need to be notarised, and therefore invoking this sampler does not create traffic to the notary. However, the notary is stored as part of the cash state and must be valid to do anything else with the cash state, therefore this sampler checks the notary identity against the network parameters of the node. * `CashIssueAndPaySampler`: this sampler client has the classname `com.r3.corda.jmeter.CashIssueAndPaySampler` and, depending on its parameters, it can start either of these flows - `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndPaymentFlow` or `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndpaymentNoSelection`. Either way it issues 2 million dollars in tokens and then transfers the sum to a configurable other node, thus invoking the full vault access, peer-to-peer communication and notarisation cycle. In addition to the parameters required for `CashIssueSampler`, this sampler also requires: diff --git a/content/en/platform/corda/4.10/enterprise/performance-testing/jmeter-testplans.md b/content/en/platform/corda/4.10/enterprise/performance-testing/jmeter-testplans.md index 6637e804fca..25ef7ed89d2 100644 --- a/content/en/platform/corda/4.10/enterprise/performance-testing/jmeter-testplans.md +++ b/content/en/platform/corda/4.10/enterprise/performance-testing/jmeter-testplans.md @@ -25,12 +25,12 @@ The testplan is a hierarchy of configuration elements. The only elements used in *Variables*, *Thread Groups*, *Samplers* and *Listeners*. Rather than creating a new testplan from scratch, it might a good idea to take a copy of one of the provided example test plans and modify that. -{{< figure alt="jmeter testplan" width=80% zoom="../resources/jmeter-testplan.png" >}} +{{< figure alt="jmeter testplan" width=80% src="../resources/jmeter-testplan.png" >}} A variables element defines key/value pairs that can be used in all following following elements instead of string literals. They can be referenced by using a `$` sign and curly braces, e.g. `${varName}`. -{{< figure alt="variables" width=80% zoom="../resources/variables.png" >}} +{{< figure alt="variables" width=80% src="../resources/variables.png" >}} A thread group collects a set of actions that form one step in the test plan. All elements within a thread group diff --git a/content/en/platform/corda/4.10/enterprise/performance-testing/performance-results.md b/content/en/platform/corda/4.10/enterprise/performance-testing/performance-results.md index 9d2f50c6143..6052ecb1ffe 100644 --- a/content/en/platform/corda/4.10/enterprise/performance-testing/performance-results.md +++ b/content/en/platform/corda/4.10/enterprise/performance-testing/performance-results.md @@ -40,7 +40,7 @@ the time of Corda Enterprise Edition 4 release). This is with each node running running **Microsoft SQL Server**. Similar results were obtained against the other supported databases. -{{< figure alt="ce4 comparison chart" width=80% zoom="/en/images/ce4-comparison-chart.png" >}} +{{< figure alt="ce4 comparison chart" width=80% src="/en/images/ce4-comparison-chart.png" >}} Figure 1 @@ -52,7 +52,7 @@ varies with the number of those payments combined together. This can be useful be a technique for even greater throughput. -{{< figure alt="states per second" width=80% zoom="/en/images/states-per-second.png" >}} +{{< figure alt="states per second" width=80% src="/en/images/states-per-second.png" >}} Figure 2 @@ -65,7 +65,7 @@ of Figure 3 were achieved using Corda Enterprise 3.0 on **Microsoft Azure** virt with minimal latency between the node VM and the database server VM. -{{< figure alt="comparison chart" width=80% zoom="/en/images/comparison-chart.png" >}} +{{< figure alt="comparison chart" width=80% src="/en/images/comparison-chart.png" >}} Figure 3 @@ -303,7 +303,7 @@ All these machines were 24 core (48 hyper-threads), based on 2x Intel Xeon E5-26 The first test performed was focused on the latency aspect. Load was generated from a single client initialised in a machine that was separate from the ones hosting the Corda nodes and their databases. The load consisted of a pre-defined number of flows (400) that were executed one after the other sequentially. Each one of those flows was initiated on the central exchange node, which was responsible for collecting signatures from all the parties involved and for finalising the transaction. Each of those flows performed a swap of two states between every pair of nodes, thus leading to a Corda transaction with 10 input and 10 output states. During the test setup, the necessary amount of states was initially issued and each one of those states would be swapped once during the test. In order to also measure the impact of transaction resolution, during the test setup each of these states was transferred bilaterally between the nodes in each pair ten times, thus generating a backchain of depth 10. This meant that during every Corda transaction, each node would have to resolve the backchain of the states belonging to the other pairs - so each node would have to resolve 80 states (8 nodes x 10 states each). In order to also measure the scaling with regard to the number of nodes, the exact same test was repeated with a varying number of participants, starting from 4 nodes and going up to 10. The test was also repeated three times with Corda Enterprise versions 4.3, 4.4, and 4.5. The goal was to isolate the benefits from bulk transaction resolution, introduced in version 4.4, and parallelised flows (`CollectSignaturesFlow` / `FinalityFlow`), introduced in version 4.5. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average latency of the flow that performed the asset swap in milliseconds. -{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.3 shows an exponential increase in the latency of the flow as the number of nodes that participate in the transaction is increased. This can be attributed to the following two reasons. Firstly, during the tests the exchange node was performing the `CollectSignaturesFlow` and `FinalityFlow` flows sequentially across the involved nodes, so the more nodes these flows had to iterate over, the more time it took. Secondly, these flows have the capability to trigger the execution of transaction resolution if they identify states for which the node is missing the provenance chain. In Corda Enterprise Edition 4.3, transaction resolution is not performed in bulk - it is performed one state at a time. As a result, every additional node causes a significant amount of extra work to be done. @@ -314,7 +314,7 @@ The main observations from the tests follow below: The second test was focused on the throughput aspect. Load was generated from multiple clients initialised on the machines that were hosting the Corda nodes, which were acting as JMeter servers orchestrated by a JMeter client running on a separate machine. The goal was to saturate the participating Corda nodes and to prevent the single client from becoming the bottleneck. During the test setup, each client issued one state to every node. Each client was then performing one flow at a time, swapping these states between the participating nodes. No backchain was generated as part of this test. As a result, the test was executed only between Corda Enterprise Edition 4.3 and Corda Enterprise Edition 4.5, and with a varying number of nodes ranging from 2 up to 10. Each of the machines driving the load was using 120 concurrent clients, which summed up to 480 concurrent clients in total. Additional measurements were performed with a varying number of clients, in order to ensure that this was the optimal number of clients to saturate the nodes without overloading them. Since the throughput was different depending on the number of participating nodes, the total number of requests was also adjusted accordingly in order to get roughly the same total duration of approximately 20 minutes. In all the scenarios, it was confirmed that the nodes had reached a stable state when the test ended. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average throughput measured in the number of flows completed per second. -{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.5 can achieve a significantly higher throughput when compared to Corda Enterprise Edition 4.3. This can be attributed to the following factors: @@ -336,9 +336,9 @@ Five different variations were tested, as follows: The purpose of this last test was to investigate the effects of these options in both throughput and latency because some of these options introduce trade-offs between these two aspects. To this end, the tests described earlier in this analysis were repeated using the variations listed above. For the latency measurements, 10 nodes were used because, thanks to the low load, there was no expectation for any big interference between nodes on the same machine. For the throughput measurements, only 4 nodes were used in order to avoid any interference between nodes on the same machine due to the high load. The results are shown in the diagrams below - the *x* axis contains the variations used, and the *y* axis shows the average throughput and latency achieved with each variation along with error bars indicating the standard deviation. -{{< figure alt="CE 4.5 variants latency comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_latency.png" >}} +{{< figure alt="CE 4.5 variants latency comparison chart" width=80% src="../resources/performance-testing/4-5_variants_latency.png" >}} -{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_throughput.png" >}} +{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% src="../resources/performance-testing/4-5_variants_throughput.png" >}} The main observations from the test are as follows: * Disabling compression leads to lower throughput and higher latency. This is expected because compression introduces a trade-off between CPU and network bandwidth utilisation and in most cases the network would prove to be a bigger bottleneck. diff --git a/content/en/platform/corda/4.10/enterprise/performance-testing/practical-considerations.md b/content/en/platform/corda/4.10/enterprise/performance-testing/practical-considerations.md index f8797af7181..2ba2ed9b205 100644 --- a/content/en/platform/corda/4.10/enterprise/performance-testing/practical-considerations.md +++ b/content/en/platform/corda/4.10/enterprise/performance-testing/practical-considerations.md @@ -94,7 +94,7 @@ To collect the output of a JMeter performance run, we need to add listeners to t This listener just lists all the runs that have been completed, one run per row, stating the thread name, sampler label, the sample time in milliseconds, the result status and the latency in milliseconds, among other (usually less useful) fields. -{{< figure alt="jmeter results table" width=80% zoom="../resources/jmeter-results-table.png" >}} +{{< figure alt="jmeter results table" width=80% src="../resources/jmeter-results-table.png" >}} This view is particularly useful when trying out any changes (new flow, new sampler, new installation) to see if it is working at all. The potential outcomes are: @@ -123,7 +123,7 @@ This listener aggregates all the runs for each thread group and the whole test p It also allows plotting these statistics in basic charts and to save the results as a csv file. This is what we use for looking at the performance results on a day to day basis. -{{< figure alt="jmeter results aggregate" width=80% zoom="../resources/jmeter-results-aggregate.png" >}} +{{< figure alt="jmeter results aggregate" width=80% src="../resources/jmeter-results-aggregate.png" >}} This listener has one line for each sampler being run as part of the test plan, and a total line summing up/averaging the results for the whole test plan. diff --git a/content/en/platform/corda/4.10/enterprise/performance-testing/r3-performance-runs.md b/content/en/platform/corda/4.10/enterprise/performance-testing/r3-performance-runs.md index 2714faadd1e..35229737e57 100644 --- a/content/en/platform/corda/4.10/enterprise/performance-testing/r3-performance-runs.md +++ b/content/en/platform/corda/4.10/enterprise/performance-testing/r3-performance-runs.md @@ -32,7 +32,7 @@ The performance network sits behind a firewall that allows incoming connections within the network can connect to each other on a range of ports (Corda Remote Procedure Call (RPC), Corda peer to peer connection (P2P) and JDBC connections to various database servers are all allowed). -{{< figure alt="performance cluster" width=80% zoom="../resources/performance-cluster.png" >}} +{{< figure alt="performance cluster" width=80% src="../resources/performance-cluster.png" >}} A Corda JMeter server instance is running on all 4 nodes and on the notary server. The JMeter client connects to the JMeter server instances via SSH tunnels. As the JMeter servers run within the firewalled network, they are free to diff --git a/content/en/platform/corda/4.10/enterprise/performance-testing/running-jmeter-corda.md b/content/en/platform/corda/4.10/enterprise/performance-testing/running-jmeter-corda.md index e8c149b626c..e5be12fcc55 100644 --- a/content/en/platform/corda/4.10/enterprise/performance-testing/running-jmeter-corda.md +++ b/content/en/platform/corda/4.10/enterprise/performance-testing/running-jmeter-corda.md @@ -54,7 +54,7 @@ interactively either locally or remotely, and view results. The UI has a set of quickly create or load a testplan, control local or remote test runs, and clear any test results collected so far. The latter is particularly important when looking at averages, as old data might skew the results being looked at. -{{< figure alt="jmeter buttons" width=80% zoom="../resources/jmeter-buttons.png" >}} +{{< figure alt="jmeter buttons" width=80% src="../resources/jmeter-buttons.png" >}} The *clear current view* button only clears the data in the currently viewed output collector - if a test plan has several output listeners defined (as in the example above, we have *Aggregate Graph*, *Graph Results* and *View Results in Table*), any collector not currently selected is not affected. *Clear all data* will clear the results from all collectors. diff --git a/content/en/platform/corda/4.11/community/api-core-types.md b/content/en/platform/corda/4.11/community/api-core-types.md index 4d5a5790fe9..b15b4367d19 100644 --- a/content/en/platform/corda/4.11/community/api-core-types.md +++ b/content/en/platform/corda/4.11/community/api-core-types.md @@ -74,11 +74,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="./resources/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="./resources/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="./resources/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="./resources/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/platform/corda/4.11/community/api-flows.md b/content/en/platform/corda/4.11/community/api-flows.md index 87a1c0c4a6f..ed7d3d66417 100644 --- a/content/en/platform/corda/4.11/community/api-flows.md +++ b/content/en/platform/corda/4.11/community/api-flows.md @@ -91,7 +91,7 @@ The `initiator`: You can visualize the work performed by initiator like this: -{{< figure alt="flow overview" width=80% zoom="./resources/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="./resources/flow-overview.png" >}} ## Responder flow class example diff --git a/content/en/platform/corda/4.11/community/api-states.md b/content/en/platform/corda/4.11/community/api-states.md index 4963d2159a0..7ebf77dd9bd 100644 --- a/content/en/platform/corda/4.11/community/api-states.md +++ b/content/en/platform/corda/4.11/community/api-states.md @@ -69,7 +69,7 @@ common sub-interfaces are `LinearState` and `OwnableState`. You can visualize the hierarchy like this: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/platform/corda/4.11/community/apps/bankinabox/user-interface/how-to.md b/content/en/platform/corda/4.11/community/apps/bankinabox/user-interface/how-to.md index c4995cb8af5..f8b0abf0eb2 100644 --- a/content/en/platform/corda/4.11/community/apps/bankinabox/user-interface/how-to.md +++ b/content/en/platform/corda/4.11/community/apps/bankinabox/user-interface/how-to.md @@ -70,7 +70,7 @@ Follow these steps to create a new customer profile. When the customer profile is created, they will not have any accounts - you will have to create them. Learn how under [Creating accounts](#create-a-current-account). {{< /note >}} -{{< figure alt="Create customer profile" width=80% zoom="/en/gifs/create-customer-biab-1.0.gif" >}} +{{< figure alt="Create customer profile" width=80% src="/en/gifs/create-customer-biab-1.0.gif" >}} ### Create a Current account @@ -94,7 +94,7 @@ When the customer profile is created, they will not have any accounts - you will 7. When an account is created, it is in **PENDING** status. This must be changed to **ACTIVE** for a customer to be able to interact with and use the account. See [Change an account status](#change-an-account-status) for more information. -{{< figure alt="Create account" width=80% zoom="/en/gifs/create-current-account-biab-1.0.gif" >}} +{{< figure alt="Create account" width=80% src="/en/gifs/create-current-account-biab-1.0.gif" >}} ### Create a Savings account @@ -140,7 +140,7 @@ An account has three statuses: **PENDING**, **ACTIVE**, and **SUSPENDED**. When If the account needs to be suspended, follow the same steps but select **SUSPENDED**. -{{< figure alt="Set account status" width=80% zoom="/en/gifs/set-account-status-biab-1.0.gif" >}} +{{< figure alt="Set account status" width=80% src="/en/gifs/set-account-status-biab-1.0.gif" >}} ### Assign or revoke a user role @@ -163,7 +163,7 @@ To assign a user role, follow these steps: 5. Click **Revoke**. A message will appear indicating that the user role was assigned successfully. -{{< figure alt="Assign role" width=80% zoom="/en/gifs/assign-a-role-biab-1.0.gif" >}} +{{< figure alt="Assign role" width=80% src="/en/gifs/assign-a-role-biab-1.0.gif" >}} #### Revoke a user role @@ -179,7 +179,7 @@ To revoke a user role, follow these steps: 5. Click **Save**. A message will appear indicating that the user role was revoked successfully. -{{< figure alt="Revoke role" width=80% zoom="/en/gifs/revoke-role-biab-1.0.gif" >}} +{{< figure alt="Revoke role" width=80% src="/en/gifs/revoke-role-biab-1.0.gif" >}} ### Issue a loan @@ -195,7 +195,7 @@ Once the account has been set to **ACTIVE**, you will have the ability to issue A loan account is created when a loan has been issued successfully. -{{< figure alt="Issue loan" width=80% zoom="/en/gifs/issue-loan-biab-1.0.gif" >}} +{{< figure alt="Issue loan" width=80% src="/en/gifs/issue-loan-biab-1.0.gif" >}} ### Approve overdrafts @@ -215,7 +215,7 @@ To approve an overdraft, follow these steps. Overdrafts can be approved whether the account is **PENDING**, **ACTIVE**, or **SUSPENDED**. {{< /note >}} -{{< figure alt="Approve overdraft" width=80% zoom="/en/gifs/approve-overdraft-biab-1.0.gif" >}} +{{< figure alt="Approve overdraft" width=80% src="/en/gifs/approve-overdraft-biab-1.0.gif" >}} ### Deposit money to an account @@ -230,7 +230,7 @@ Follow these steps to deposit money to a customer account. 4. Click **Save**. You will receive a message indicating that the deposit was successful. -{{< figure alt="Deposit" width=80% zoom="/en/gifs/deposit-biab-1.0.gif" >}} +{{< figure alt="Deposit" width=80% src="/en/gifs/deposit-biab-1.0.gif" >}} ### Register as a user on Bank in a Box @@ -251,7 +251,7 @@ You must be registered as a **Customer** or **Admin** on Bank in a Box to perfor 5. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update customer profile @@ -284,7 +284,7 @@ An **Admin user** can set an account's **Withdrawal daily limit** or **Transfer 2. Click **Save** when you have entered the desired limits. A message will appear indicating that the limits have been saved successfully. -{{< figure alt="Set withdrawal and transfer limits - admin" width=80% zoom="/en/gifs/set-limits-admin-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - admin" width=80% src="/en/gifs/set-limits-admin-biab-1.0.gif" >}} ## Customer tasks @@ -309,12 +309,12 @@ Follow these steps to create a new intrabank payment. 6. Click **Save**. You will receive a notification indicating that the payment was created successfully. You will also receive notifications indicating any changes in your account balances. -{{< figure alt="Create intrabank payment" width=80% zoom="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} +{{< figure alt="Create intrabank payment" width=80% src="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} After making a payment, you can view the details of this transaction on the Transactions screen. -{{< figure alt="View transaction" width="800" width=80% zoom="/en/gifs/view-transaction-biab-1.0.gif" >}} +{{< figure alt="View transaction" width="800" width=80% src="/en/gifs/view-transaction-biab-1.0.gif" >}} ### Create a recurring payment @@ -338,7 +338,7 @@ Follow these steps to create a recurring payment: 3. You will be taken back to the **Recurring payments screen** where you will receive a message indicating that the recurring payment was created successfully. -{{< figure alt="Recurring payment" width=80% zoom="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} +{{< figure alt="Recurring payment" width=80% src="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} {{< note >}} This payment will not appear on the **Recurring payments screen** until the first iteration has occurred. @@ -367,7 +367,7 @@ You must be registered as a Customer or Admin on Bank in a Box to perform tasks. 7. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update a customer profile @@ -406,4 +406,4 @@ To set these limits as a **Customer**, follow these steps. 4. Click **Save**. You will be taken back to the Account page where you will receive a message indicating that the limits have been updated successfully. -{{< figure alt="Set withdrawal and transfer limits - customer" width=80% zoom="/en/gifs/set-limits-customer-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - customer" width=80% src="/en/gifs/set-limits-customer-biab-1.0.gif" >}} diff --git a/content/en/platform/corda/4.11/community/building-the-docs.md b/content/en/platform/corda/4.11/community/building-the-docs.md index c0e508f43d2..c11453a5191 100644 --- a/content/en/platform/corda/4.11/community/building-the-docs.md +++ b/content/en/platform/corda/4.11/community/building-the-docs.md @@ -76,7 +76,7 @@ Or if you want to use Docker: As a result, there will be an extra icon in the title bar of your local docs site, which should open the current page in Visual Studio Code: -{{< figure alt="Visual Studio Code" width=80% zoom="/en/images/hugo-vscode-page-edit.png" >}} +{{< figure alt="Visual Studio Code" width=80% src="/en/images/hugo-vscode-page-edit.png" >}} ## Edit web pages directly in Atom diff --git a/content/en/platform/corda/4.11/community/cipher-suites.md b/content/en/platform/corda/4.11/community/cipher-suites.md index f2c8cc2f0c5..23bb373f3a4 100644 --- a/content/en/platform/corda/4.11/community/cipher-suites.md +++ b/content/en/platform/corda/4.11/community/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates]({{< relref "permissioning.md" >}})): -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/platform/corda/4.11/community/contract-irs.md b/content/en/platform/corda/4.11/community/contract-irs.md index 42f58af1f85..2b3d8e53fd6 100644 --- a/content/en/platform/corda/4.11/community/contract-irs.md +++ b/content/en/platform/corda/4.11/community/contract-irs.md @@ -48,7 +48,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="/en/images/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="/en/images/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/platform/corda/4.11/community/cordapp-advanced-concepts.md b/content/en/platform/corda/4.11/community/cordapp-advanced-concepts.md index 5631f508a20..f25c5bdcc8e 100644 --- a/content/en/platform/corda/4.11/community/cordapp-advanced-concepts.md +++ b/content/en/platform/corda/4.11/community/cordapp-advanced-concepts.md @@ -73,7 +73,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/platform/corda/4.11/community/cordapp-overview.md b/content/en/platform/corda/4.11/community/cordapp-overview.md index 6544c273bd6..4f1cf45a548 100644 --- a/content/en/platform/corda/4.11/community/cordapp-overview.md +++ b/content/en/platform/corda/4.11/community/cordapp-overview.md @@ -22,7 +22,7 @@ CorDapps (Corda Distributed Applications) are distributed applications that run CorDapp is to allow nodes to reach agreement on updates to the ledger. They achieve this goal by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="/en/images/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="/en/images/node-diagram.png" >}} ## CorDapp components diff --git a/content/en/platform/corda/4.11/community/financial-model.md b/content/en/platform/corda/4.11/community/financial-model.md index 578f1cdaa18..439c3a51151 100644 --- a/content/en/platform/corda/4.11/community/financial-model.md +++ b/content/en/platform/corda/4.11/community/financial-model.md @@ -93,6 +93,6 @@ countable (in cents), barrels of West Texas crude are fungible and countable (oi container), shares of the same class in a specific company are fungible and countable, and so on. The following diagram illustrates the complete Contract State hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Note there are currently two packages, a core library and a finance model specific library. Developers may re-use or extend the Finance types directly or write their own by extending the base types from the Core library. diff --git a/content/en/platform/corda/4.11/community/key-concepts-consensus.md b/content/en/platform/corda/4.11/community/key-concepts-consensus.md index d1c2adbe731..c774452fee6 100644 --- a/content/en/platform/corda/4.11/community/key-concepts-consensus.md +++ b/content/en/platform/corda/4.11/community/key-concepts-consensus.md @@ -49,7 +49,7 @@ transferring a treasury bond, the bond transfer is only valid if: Walking the chain for this transaction would look like this: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a node may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer. The @@ -68,7 +68,7 @@ proposals: Both transactions will achieve validity consensus, yet Alice has managed to “double-spend” her USD to get double the amount of GBP and EUR: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/platform/corda/4.11/community/key-concepts-contracts.md b/content/en/platform/corda/4.11/community/key-concepts-contracts.md index 2d375d7f2c8..76696123284 100644 --- a/content/en/platform/corda/4.11/community/key-concepts-contracts.md +++ b/content/en/platform/corda/4.11/community/key-concepts-contracts.md @@ -55,7 +55,7 @@ transaction gathers all the required signatures, it can't be executed unless it Each transaction [state]({{< relref "key-concepts-states.md" >}}) specifies a *contract type*. The contract specified takes the transaction as input, and determines if the transaction is valid based on the contract's internal rules. The contract must evaluate every input state and every output state. -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code can: * Check the number of inputs, outputs, commands, or attachments. diff --git a/content/en/platform/corda/4.11/community/key-concepts-ecosystem.md b/content/en/platform/corda/4.11/community/key-concepts-ecosystem.md index b9c7e11dc23..caa6d472488 100644 --- a/content/en/platform/corda/4.11/community/key-concepts-ecosystem.md +++ b/content/en/platform/corda/4.11/community/key-concepts-ecosystem.md @@ -32,7 +32,7 @@ title: Networks, identity, and discovery ## What is a network? On Corda, people and business interact by communicating over a peer-to-peer network of [Corda nodes]({{< relref "key-concepts-node.md" >}}). Each node represents a legal entity running Corda and one or more Corda distributed applications, known as [CorDapps]({{< relref "cordapp-overview.md" >}}). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} Corda is different from other distributed ledgers because all communication between nodes is point-to-point, and only shared on a need-to-know basis. It is also encrypted using transport-layer security. There are *no global broadcasts* to all parties on a network, but all of the nodes in a network can send messages directly to other nodes. If the recipient is offline, the message waits in an outbound queue until they are online again—just like an email. ## Join a network diff --git a/content/en/platform/corda/4.11/community/key-concepts-flows.md b/content/en/platform/corda/4.11/community/key-concepts-flows.md index 01e307dfef1..a80fdd07650 100644 --- a/content/en/platform/corda/4.11/community/key-concepts-flows.md +++ b/content/en/platform/corda/4.11/community/key-concepts-flows.md @@ -35,7 +35,7 @@ must specify what information needs to be sent, to which counterparties, and in Here is a visualisation of Alice and Bob agreeing a ledger update using this process: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -44,7 +44,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is a diagram showing the flow's steps used between Alice and Bob to perform the ledger update: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/platform/corda/4.11/community/key-concepts-ledger.md b/content/en/platform/corda/4.11/community/key-concepts-ledger.md index 26bc448ede6..526681954d2 100644 --- a/content/en/platform/corda/4.11/community/key-concepts-ledger.md +++ b/content/en/platform/corda/4.11/community/key-concepts-ledger.md @@ -39,7 +39,7 @@ loan are Alice and Bob, then they are the only nodes that ever see or store this This diagram shows a network with five nodes (Alice, Bob, Carl, Demi, and Ed). Each numbered circle on an intersection represents a fact shared between two or more nodes: -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} In the diagram, facts 1 and 7 are known by both Alice and Bob. Alice only shares facts with Bob, Alice doesn't share any facts with Carl, Demi, or Ed. @@ -56,7 +56,7 @@ each node maintains its own vault, which contains all of its known facts. You can think of a vault as being a database or simple table. In this diagram, facts 1 and 7 appear on both Alice's vault and Bob's vault, and are therefore shared facts: -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} When multiple nodes on a network share an evolving fact, the changes to the fact update at the same time in each node's vault. This means that Alice and Bob will both see an *identical version* of shared facts 1 and 7. diff --git a/content/en/platform/corda/4.11/community/key-concepts-node.md b/content/en/platform/corda/4.11/community/key-concepts-node.md index 2bea3448317..1292cb3a7d3 100644 --- a/content/en/platform/corda/4.11/community/key-concepts-node.md +++ b/content/en/platform/corda/4.11/community/key-concepts-node.md @@ -35,7 +35,7 @@ title: Nodes A Corda node runs within a Java Virtual Machine (JVM) runtime environment with a [unique network identity]({{< relref "key-concepts-ecosystem.md#node-identities" >}}). JVM runtime environments provide a consistent platform on which you can run and deploy Java applications, such as Corda services and CorDapps. Here is a visualization of the node’s internal architecture: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: diff --git a/content/en/platform/corda/4.11/community/key-concepts-states.md b/content/en/platform/corda/4.11/community/key-concepts-states.md index cb52b14d2b2..97fbb2ef75b 100644 --- a/content/en/platform/corda/4.11/community/key-concepts-states.md +++ b/content/en/platform/corda/4.11/community/key-concepts-states.md @@ -35,7 +35,7 @@ You can use states to represent any type of data, and any kind of fact. For exam This state represents an IOU—an agreement that Alice owes Bob £10: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} In addition to information about the fact, the state contains a reference to the **[contract]({{< relref "key-concepts-contracts.md" >}})**. Contracts govern the evolution of states. @@ -47,14 +47,14 @@ When a fact changes, one of the state's participants creates a new state and mar For example, if Alice pays Bob £5, the state sequence would be: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a **vault**. This is the node's database used to store current and historic states where the node is a participant. For example: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} From each node's point of view, the ledger is the current (non-historic) states where that node is a participant. diff --git a/content/en/platform/corda/4.11/community/key-concepts-tearoffs.md b/content/en/platform/corda/4.11/community/key-concepts-tearoffs.md index a69e6dd0f2f..e6b2369726a 100644 --- a/content/en/platform/corda/4.11/community/key-concepts-tearoffs.md +++ b/content/en/platform/corda/4.11/community/key-concepts-tearoffs.md @@ -39,7 +39,7 @@ Merkle trees split transactions into "leaves". Each leaf contains either an input, an output, a command, or an attachment. The final nested tree structure also contains the other fields of the transaction, such as the time window, the notary, and the required signers. The only component type that requires two trees instead of one is the command, which is split into command data and required signers for visibility purposes. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} Corda uses one nested Merkle tree per component type. A component sub-tree is generated for each component type (for example, inputs, outputs, or attachments). The roots of these sub-trees @@ -65,7 +65,7 @@ obtained belongs to that particular transaction. In this example, assume that only the first command should be visible to the oracle. You must provide guarantees that all the commands the oracle needs to sign are visible to the oracle entity, but no other data. The transaction would be represented in the Merkle tree structure like this: -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} The blue nodes and `H(c2)` are provided to the oracle service, while the black ones are omitted. The oracle needs `H(c2)` so it can compute `H(commandData)` without being to able to see the second command. At the same time, this ensures that `CommandData1` is part of the transaction. All signers are visible as @@ -79,4 +79,4 @@ To send the same transaction to a non-validating notary, hide all components apart from input states, time window, and the notary information. This data is enough for the notary to know which input states to check for double-spending, if the time-window is valid, and if the transaction is being notarized by the correct notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/platform/corda/4.11/community/key-concepts-time-windows.md b/content/en/platform/corda/4.11/community/key-concepts-time-windows.md index 4dd732b08d6..8aa8e6293b8 100644 --- a/content/en/platform/corda/4.11/community/key-concepts-time-windows.md +++ b/content/en/platform/corda/4.11/community/key-concepts-time-windows.md @@ -46,7 +46,7 @@ trade, or requesting human sign-off. Times in transactions are specified as time *windows*, not absolute times. Time windows can be open-ended, and specify only “before” **or** “after”, or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} When both a before and an after time are included the transaction occurred at some point within that time window. diff --git a/content/en/platform/corda/4.11/community/key-concepts-transactions.md b/content/en/platform/corda/4.11/community/key-concepts-transactions.md index 27e26d92cfd..3d7e7d74b04 100644 --- a/content/en/platform/corda/4.11/community/key-concepts-transactions.md +++ b/content/en/platform/corda/4.11/community/key-concepts-transactions.md @@ -37,7 +37,7 @@ Every [state]({{< relref "key-concepts-states.md" >}}) is *immutable*—it can't Here is an example of a transaction with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type. Transactions can: * Include different types of states representing multiple financial instruments, such as cash or bonds. @@ -65,21 +65,21 @@ Input state references consist of: You can see how this works in this example transaction: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} ## Committing transactions to the ledger Initially, a transaction is only a proposal to update the ledger. It represents the future state of the ledger desired by the transaction builders. -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To be committed to the ledger, the transaction must receive signatures from all the *required signers*. Each required signer appends their signature to the transaction to approve the proposal. -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If the transaction gathers the required signatures, it is committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions. @@ -121,7 +121,7 @@ For example, suppose Alice uses $5 cash to pay off $5 of an IOU with Bob. This transaction contains a *settlement command* which reduces the amount outstanding on the IOU, and a *payment command* which changes the ownership of $5 from Alice to Bob. It also has two supporting attachments, and is notarized by `NotaryClusterA` if the notary pool receives it within the specified time window: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -145,7 +145,7 @@ listed in the commands, you get the list of the transaction’s required signers This situation would look like this: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/platform/corda/4.11/community/key-concepts-vault.md b/content/en/platform/corda/4.11/community/key-concepts-vault.md index f3c36fbd617..3ff209105be 100644 --- a/content/en/platform/corda/4.11/community/key-concepts-vault.md +++ b/content/en/platform/corda/4.11/community/key-concepts-vault.md @@ -45,7 +45,7 @@ The vault supports the management of data in both authoritative **on-ledger** fo This diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} You can see: diff --git a/content/en/platform/corda/4.11/community/network-builder.md b/content/en/platform/corda/4.11/community/network-builder.md index ca6c5c75b49..f3a5e4aedc1 100644 --- a/content/en/platform/corda/4.11/community/network-builder.md +++ b/content/en/platform/corda/4.11/community/network-builder.md @@ -21,7 +21,7 @@ title: Corda Network Builder The Corda Network Builder is a tool for building Corda networks for testing purposes. It leverages Docker and containers to abstract the complexity of managing a distributed network away from the user. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} The network you build will either be made up of local `Docker` nodes *or* of nodes spread across Azure containers. For each node a separate Docker image is built based on [corda/community:4.11.5-zulu-openjdk8](https://hub.docker.com/layers/corda/community/4.11.5-zulu-openjdk8/images/sha256-241351e48f0a649d4552d6951e15f09981b6fa32c112d275667d295875540275). diff --git a/content/en/platform/corda/4.11/community/node-administration.md b/content/en/platform/corda/4.11/community/node-administration.md index 7fa9ce64b2a..08d6cc1f052 100644 --- a/content/en/platform/corda/4.11/community/node-administration.md +++ b/content/en/platform/corda/4.11/community/node-administration.md @@ -173,7 +173,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ## Memory usage and tuning diff --git a/content/en/platform/corda/4.11/community/node-database-tables.md b/content/en/platform/corda/4.11/community/node-database-tables.md index 0251df27d62..7d00b5b7da4 100644 --- a/content/en/platform/corda/4.11/community/node-database-tables.md +++ b/content/en/platform/corda/4.11/community/node-database-tables.md @@ -49,7 +49,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more here: [The network map]({{< relref "network-map.md" >}}) -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -178,7 +178,7 @@ Read more in [the ledger]({{< relref "key-concepts-ledger.md" >}}) Read more in [Working with attachments]({{< relref "../enterprise/get-started/tutorials/supplementary-tutorials/tutorial-attachments.md" >}}) and [Node services]({{< relref "node-services.md" >}}) -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -470,7 +470,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -499,7 +499,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/platform/corda/4.11/community/permissioning.md b/content/en/platform/corda/4.11/community/permissioning.md index 1e5011e0649..c42e721ec93 100644 --- a/content/en/platform/corda/4.11/community/permissioning.md +++ b/content/en/platform/corda/4.11/community/permissioning.md @@ -52,7 +52,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/platform/corda/4.11/community/upgrading-cordapps.md b/content/en/platform/corda/4.11/community/upgrading-cordapps.md index 91f85183026..a91d695d01c 100644 --- a/content/en/platform/corda/4.11/community/upgrading-cordapps.md +++ b/content/en/platform/corda/4.11/community/upgrading-cordapps.md @@ -74,7 +74,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="/en/images/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="/en/images/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/platform/corda/4.11/enterprise/api-core-types.md b/content/en/platform/corda/4.11/enterprise/api-core-types.md index a7046fc2f1c..db04c061e2c 100644 --- a/content/en/platform/corda/4.11/enterprise/api-core-types.md +++ b/content/en/platform/corda/4.11/enterprise/api-core-types.md @@ -66,11 +66,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="./resources/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="./resources/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="./resources/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="./resources/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/platform/corda/4.11/enterprise/apps/bankinabox/user-interface/how-to.md b/content/en/platform/corda/4.11/enterprise/apps/bankinabox/user-interface/how-to.md index 2f0e7059142..9de7eaa5c02 100644 --- a/content/en/platform/corda/4.11/enterprise/apps/bankinabox/user-interface/how-to.md +++ b/content/en/platform/corda/4.11/enterprise/apps/bankinabox/user-interface/how-to.md @@ -70,7 +70,7 @@ Follow these steps to create a new customer profile. When the customer profile is created, they will not have any accounts - you will have to create them. Learn how under [Creating accounts](#create-a-current-account). {{< /note >}} -{{< figure alt="Create customer profile" width=80% zoom="/en/gifs/create-customer-biab-1.0.gif" >}} +{{< figure alt="Create customer profile" width=80% src="/en/gifs/create-customer-biab-1.0.gif" >}} ### Create a Current account @@ -94,7 +94,7 @@ When the customer profile is created, they will not have any accounts - you will 7. When an account is created, it is in **PENDING** status. This must be changed to **ACTIVE** for a customer to be able to interact with and use the account. See [Change an account status](#change-an-account-status) for more information. -{{< figure alt="Create account" width=80% zoom="/en/gifs/create-current-account-biab-1.0.gif" >}} +{{< figure alt="Create account" width=80% src="/en/gifs/create-current-account-biab-1.0.gif" >}} ### Create a Savings account @@ -140,7 +140,7 @@ An account has three statuses: **PENDING**, **ACTIVE**, and **SUSPENDED**. When If the account needs to be suspended, follow the same steps but select **SUSPENDED**. -{{< figure alt="Set account status" width=80% zoom="/en/gifs/set-account-status-biab-1.0.gif" >}} +{{< figure alt="Set account status" width=80% src="/en/gifs/set-account-status-biab-1.0.gif" >}} ### Assign or revoke a user role @@ -163,7 +163,7 @@ To assign a user role, follow these steps: 5. Click **Revoke**. A message will appear indicating that the user role was assigned successfully. -{{< figure alt="Assign role" width=80% zoom="/en/gifs/assign-a-role-biab-1.0.gif" >}} +{{< figure alt="Assign role" width=80% src="/en/gifs/assign-a-role-biab-1.0.gif" >}} #### Revoke a user role @@ -179,7 +179,7 @@ To revoke a user role, follow these steps: 5. Click **Save**. A message will appear indicating that the user role was revoked successfully. -{{< figure alt="Revoke role" width=80% zoom="/en/gifs/revoke-role-biab-1.0.gif" >}} +{{< figure alt="Revoke role" width=80% src="/en/gifs/revoke-role-biab-1.0.gif" >}} ### Issue a loan @@ -195,7 +195,7 @@ Once the account has been set to **ACTIVE**, you will have the ability to issue A loan account is created when a loan has been issued successfully. -{{< figure alt="Issue loan" width=80% zoom="/en/gifs/issue-loan-biab-1.0.gif" >}} +{{< figure alt="Issue loan" width=80% src="/en/gifs/issue-loan-biab-1.0.gif" >}} ### Approve overdrafts @@ -215,7 +215,7 @@ To approve an overdraft, follow these steps. Overdrafts can be approved whether the account is **PENDING**, **ACTIVE**, or **SUSPENDED**. {{< /note >}} -{{< figure alt="Approve overdraft" width=80% zoom="/en/gifs/approve-overdraft-biab-1.0.gif" >}} +{{< figure alt="Approve overdraft" width=80% src="/en/gifs/approve-overdraft-biab-1.0.gif" >}} ### Deposit money to an account @@ -230,7 +230,7 @@ Follow these steps to deposit money to a customer account. 4. Click **Save**. You will receive a message indicating that the deposit was successful. -{{< figure alt="Deposit" width=80% zoom="/en/gifs/deposit-biab-1.0.gif" >}} +{{< figure alt="Deposit" width=80% src="/en/gifs/deposit-biab-1.0.gif" >}} ### Register as a user on Bank in a Box @@ -251,7 +251,7 @@ You must be registered as a **Customer** or **Admin** on Bank in a Box to perfor 5. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update customer profile @@ -284,7 +284,7 @@ An **Admin user** can set an account's **Withdrawal daily limit** or **Transfer 2. Click **Save** when you have entered the desired limits. A message will appear indicating that the limits have been saved successfully. -{{< figure alt="Set withdrawal and transfer limits - admin" width=80% zoom="/en/gifs/set-limits-admin-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - admin" width=80% src="/en/gifs/set-limits-admin-biab-1.0.gif" >}} ## Customer tasks @@ -309,12 +309,12 @@ Follow these steps to create a new intrabank payment. 6. Click **Save**. You will receive a notification indicating that the payment was created successfully. You will also receive notifications indicating any changes in your account balances. -{{< figure alt="Create intrabank payment" width=80% zoom="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} +{{< figure alt="Create intrabank payment" width=80% src="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} After making a payment, you can view the details of this transaction on the Transactions screen. -{{< figure alt="View transaction" width="800" width=80% zoom="/en/gifs/view-transaction-biab-1.0.gif" >}} +{{< figure alt="View transaction" width="800" width=80% src="/en/gifs/view-transaction-biab-1.0.gif" >}} ### Create a recurring payment @@ -338,7 +338,7 @@ Follow these steps to create a recurring payment: 3. You will be taken back to the **Recurring payments screen** where you will receive a message indicating that the recurring payment was created successfully. -{{< figure alt="Recurring payment" width=80% zoom="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} +{{< figure alt="Recurring payment" width=80% src="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} {{< note >}} This payment will not appear on the **Recurring payments screen** until the first iteration has occurred. @@ -367,7 +367,7 @@ You must be registered as a Customer or Admin on Bank in a Box to perform tasks. 7. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update a customer profile @@ -406,4 +406,4 @@ To set these limits as a **Customer**, follow these steps. 4. Click **Save**. You will be taken back to the Account page where you will receive a message indicating that the limits have been updated successfully. -{{< figure alt="Set withdrawal and transfer limits - customer" width=80% zoom="/en/gifs/set-limits-customer-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - customer" width=80% src="/en/gifs/set-limits-customer-biab-1.0.gif" >}} diff --git a/content/en/platform/corda/4.11/enterprise/contract-irs.md b/content/en/platform/corda/4.11/enterprise/contract-irs.md index abee73edee2..f0a31450d3a 100644 --- a/content/en/platform/corda/4.11/enterprise/contract-irs.md +++ b/content/en/platform/corda/4.11/enterprise/contract-irs.md @@ -45,7 +45,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="./resources/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="./resources/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/platform/corda/4.11/enterprise/cordapp-advanced-concepts.md b/content/en/platform/corda/4.11/enterprise/cordapp-advanced-concepts.md index 81c69999fc0..f62dd52042f 100644 --- a/content/en/platform/corda/4.11/enterprise/cordapp-advanced-concepts.md +++ b/content/en/platform/corda/4.11/enterprise/cordapp-advanced-concepts.md @@ -71,7 +71,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="./resources/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="./resources/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/platform/corda/4.11/enterprise/cordapps/api-flows.md b/content/en/platform/corda/4.11/enterprise/cordapps/api-flows.md index 1a8dba77d53..cdf37ea4c25 100644 --- a/content/en/platform/corda/4.11/enterprise/cordapps/api-flows.md +++ b/content/en/platform/corda/4.11/enterprise/cordapps/api-flows.md @@ -91,7 +91,7 @@ The `initiator`: You can visualize the work performed by initiator like this: -{{< figure alt="flow overview" width=80% zoom="../resources/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="../resources/flow-overview.png" >}} ## Responder flow class example diff --git a/content/en/platform/corda/4.11/enterprise/cordapps/api-states.md b/content/en/platform/corda/4.11/enterprise/cordapps/api-states.md index 4f5f8b226e4..1141136fe67 100644 --- a/content/en/platform/corda/4.11/enterprise/cordapps/api-states.md +++ b/content/en/platform/corda/4.11/enterprise/cordapps/api-states.md @@ -62,7 +62,7 @@ states evolve in a straight line by superseding themselves. You can visualize the hierarchy like this: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/platform/corda/4.11/enterprise/cordapps/cordapp-overview.md b/content/en/platform/corda/4.11/enterprise/cordapps/cordapp-overview.md index 221e2fa4114..9647ae31263 100644 --- a/content/en/platform/corda/4.11/enterprise/cordapps/cordapp-overview.md +++ b/content/en/platform/corda/4.11/enterprise/cordapps/cordapp-overview.md @@ -31,7 +31,7 @@ CorDapps are: A Corda Distributed Application (CorDapp) solves a specific problem using the Corda framework. CorDapps are stored on Corda nodes and executed on the Corda network. This *distributes* the app, allowing it to run on multiple systems simultaneously—unlike traditional apps, which utilize one dedicated system to achieve an assigned task. CorDapps let nodes communicate with each other to reach agreement on updates to the ledger by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="../resources/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="../resources/node-diagram.png" >}} ## Glossary diff --git a/content/en/platform/corda/4.11/enterprise/cordapps/upgrading-cordapps.md b/content/en/platform/corda/4.11/enterprise/cordapps/upgrading-cordapps.md index 52b26b873e3..745200f9818 100644 --- a/content/en/platform/corda/4.11/enterprise/cordapps/upgrading-cordapps.md +++ b/content/en/platform/corda/4.11/enterprise/cordapps/upgrading-cordapps.md @@ -68,7 +68,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="../resources/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="../resources/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/platform/corda/4.11/enterprise/financial-model.md b/content/en/platform/corda/4.11/enterprise/financial-model.md index 497d9febccc..a5185828ba6 100644 --- a/content/en/platform/corda/4.11/enterprise/financial-model.md +++ b/content/en/platform/corda/4.11/enterprise/financial-model.md @@ -92,6 +92,6 @@ countable (in cents), barrels of oil are fungible and countable (oil from two sm container), shares of the same class in a specific company are fungible and countable, and so on. This diagram illustrates the complete contract state hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Corda provides two packages: a core library and a finance model-specific library. You can re-use or extend the finance types directly, or write your own by extending the base types from the core library. diff --git a/content/en/platform/corda/4.11/enterprise/health-survey.md b/content/en/platform/corda/4.11/enterprise/health-survey.md index dfe52e9b0c3..3cc83acd3f5 100644 --- a/content/en/platform/corda/4.11/enterprise/health-survey.md +++ b/content/en/platform/corda/4.11/enterprise/health-survey.md @@ -116,7 +116,7 @@ The Corda Health Survey currently does not support testing RPC communication if The tool generates the archive of the collected files in the same directory it is ran in. The names are in the format: `report-date-time.zip` -{{< figure alt="health survey photo" width=80% zoom="resources/health-survey-photo.png" >}} +{{< figure alt="health survey photo" width=80% src="resources/health-survey-photo.png" >}} ## Deployment health check diff --git a/content/en/platform/corda/4.11/enterprise/key-concepts-consensus.md b/content/en/platform/corda/4.11/enterprise/key-concepts-consensus.md index 9fc37abe317..8fabe778c4c 100644 --- a/content/en/platform/corda/4.11/enterprise/key-concepts-consensus.md +++ b/content/en/platform/corda/4.11/enterprise/key-concepts-consensus.md @@ -49,7 +49,7 @@ transferring a treasury bond, the bond transfer is only valid if: Walking the chain for this transaction would look like this: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a node may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer. The @@ -68,7 +68,7 @@ proposals: Both transactions will achieve validity consensus, yet Alice has managed to “double-spend” her USD to get double the amount of GBP and EUR: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/platform/corda/4.11/enterprise/key-concepts-contracts.md b/content/en/platform/corda/4.11/enterprise/key-concepts-contracts.md index 237f786e0e3..8af27853fce 100644 --- a/content/en/platform/corda/4.11/enterprise/key-concepts-contracts.md +++ b/content/en/platform/corda/4.11/enterprise/key-concepts-contracts.md @@ -55,7 +55,7 @@ transaction gathers all the required signatures, it can't be executed unless it Each transaction [state]({{< relref "key-concepts-states.md" >}}) specifies a *contract type*. The contract specified takes the transaction as input, and determines if the transaction is valid based on the contract's internal rules. The contract must evaluate every input state and every output state. -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code can: * Check the number of inputs, outputs, commands, or attachments. diff --git a/content/en/platform/corda/4.11/enterprise/key-concepts-ecosystem.md b/content/en/platform/corda/4.11/enterprise/key-concepts-ecosystem.md index 396911144eb..722ec39379b 100644 --- a/content/en/platform/corda/4.11/enterprise/key-concepts-ecosystem.md +++ b/content/en/platform/corda/4.11/enterprise/key-concepts-ecosystem.md @@ -32,7 +32,7 @@ title: Networks, identity, and discovery ## What is a network? On Corda, people and business interact by communicating over a peer-to-peer network of [Corda nodes]({{< relref "key-concepts-node.md" >}}). Each node represents a legal entity running Corda and one or more Corda distributed applications, known as [CorDapps]({{< relref "cordapps/cordapp-overview.md" >}}). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} Corda is different from other distributed ledgers because all communication between nodes is point-to-point, and only shared on a need-to-know basis. It is also encrypted using transport-layer security. There are *no global broadcasts* to all parties on a network, but all of the nodes in a network can send messages directly to other nodes. If the recipient is offline, the message waits in an outbound queue until they are online again—just like an email. ## Join a network diff --git a/content/en/platform/corda/4.11/enterprise/key-concepts-flows.md b/content/en/platform/corda/4.11/enterprise/key-concepts-flows.md index 220c46a2cb7..6c6729854f1 100644 --- a/content/en/platform/corda/4.11/enterprise/key-concepts-flows.md +++ b/content/en/platform/corda/4.11/enterprise/key-concepts-flows.md @@ -35,7 +35,7 @@ must specify what information needs to be sent, to which counterparties, and in Here is a visualisation of Alice and Bob agreeing a ledger update using this process: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -44,7 +44,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is a diagram showing the flow's steps used between Alice and Bob to perform the ledger update: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/platform/corda/4.11/enterprise/key-concepts-ledger.md b/content/en/platform/corda/4.11/enterprise/key-concepts-ledger.md index c4a8276fd12..3cc8bc43a21 100644 --- a/content/en/platform/corda/4.11/enterprise/key-concepts-ledger.md +++ b/content/en/platform/corda/4.11/enterprise/key-concepts-ledger.md @@ -39,7 +39,7 @@ loan are Alice and Bob, then they are the only nodes that ever see or store this This diagram shows a network with five nodes (Alice, Bob, Carl, Demi, and Ed). Each numbered circle on an intersection represents a fact shared between two or more nodes: -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} In the diagram, facts 1 and 7 are known by both Alice and Bob. Alice only shares facts with Bob, Alice doesn't share any facts with Carl, Demi, or Ed. @@ -56,7 +56,7 @@ each node maintains its own vault, which contains all of its known facts. You can think of a vault as being a database or simple table. In this diagram, facts 1 and 7 appear on both Alice's vault and Bob's vault, and are therefore shared facts: -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} When multiple nodes on a network share an evolving fact, the changes to the fact update at the same time in each node's vault. This means that Alice and Bob will both see an *identical version* of shared facts 1 and 7. diff --git a/content/en/platform/corda/4.11/enterprise/key-concepts-node.md b/content/en/platform/corda/4.11/enterprise/key-concepts-node.md index 74fcf5f0f25..fb74046502f 100644 --- a/content/en/platform/corda/4.11/enterprise/key-concepts-node.md +++ b/content/en/platform/corda/4.11/enterprise/key-concepts-node.md @@ -35,7 +35,7 @@ title: Nodes A Corda node runs within a Java Virtual Machine (JVM) runtime environment with a [unique network identity]({{< relref "key-concepts-ecosystem.md#node-identities" >}}). JVM runtime environments provide a consistent platform on which you can run and deploy Java applications, such as Corda services and CorDapps. Here is a visualization of the node’s internal architecture: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: diff --git a/content/en/platform/corda/4.11/enterprise/key-concepts-states.md b/content/en/platform/corda/4.11/enterprise/key-concepts-states.md index 1564ccfc595..d2a5ed21a34 100644 --- a/content/en/platform/corda/4.11/enterprise/key-concepts-states.md +++ b/content/en/platform/corda/4.11/enterprise/key-concepts-states.md @@ -35,7 +35,7 @@ You can use states to represent any type of data, and any kind of fact. For exam This state represents an IOU—an agreement that Alice owes Bob £10: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} In addition to information about the fact, the state contains a reference to the **[contract]({{< relref "key-concepts-contracts.md" >}})**. Contracts govern the evolution of states. @@ -47,14 +47,14 @@ When a fact changes, one of the state's participants creates a new state and mar For example, if Alice pays Bob £5, the state sequence would be: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a **vault**. This is the node's database used to store current and historic states where the node is a participant. For example: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} From each node's point of view, the ledger is the current (non-historic) states where that node is a participant. diff --git a/content/en/platform/corda/4.11/enterprise/key-concepts-tearoffs.md b/content/en/platform/corda/4.11/enterprise/key-concepts-tearoffs.md index f609d24aef2..0e98e4602e9 100644 --- a/content/en/platform/corda/4.11/enterprise/key-concepts-tearoffs.md +++ b/content/en/platform/corda/4.11/enterprise/key-concepts-tearoffs.md @@ -39,7 +39,7 @@ Merkle trees split transactions into "leaves". Each leaf contains either an input, an output, a command, or an attachment. The final nested tree structure also contains the other fields of the transaction, such as the time window, the notary, and the required signers. The only component type that requires two trees instead of one is the command, which is split into command data and required signers for visibility purposes. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} Corda uses one nested Merkle tree per component type. A component sub-tree is generated for each component type (for example, inputs, outputs, or attachments). The roots of these sub-trees @@ -65,7 +65,7 @@ obtained belongs to that particular transaction. In this example, assume that only the first command should be visible to the oracle. You must provide guarantees that all the commands the oracle needs to sign are visible to the oracle entity, but no other data. The transaction would be represented in the Merkle tree structure like this: -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} The blue nodes and `H(c2)` are provided to the oracle service, while the black ones are omitted. The oracle needs `H(c2)` so it can compute `H(commandData)` without being to able to see the second command. At the same time, this ensures that `CommandData1` is part of the transaction. All signers are visible as @@ -79,4 +79,4 @@ To send the same transaction to a non-validating notary, hide all components apart from input states, time window, and the notary information. This data is enough for the notary to know which input states to check for double-spending, if the time-window is valid, and if the transaction is being notarized by the correct notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/platform/corda/4.11/enterprise/key-concepts-time-windows.md b/content/en/platform/corda/4.11/enterprise/key-concepts-time-windows.md index 37d93faa391..95eea8fb2eb 100644 --- a/content/en/platform/corda/4.11/enterprise/key-concepts-time-windows.md +++ b/content/en/platform/corda/4.11/enterprise/key-concepts-time-windows.md @@ -46,7 +46,7 @@ trade, or requesting human sign-off. Times in transactions are specified as time *windows*, not absolute times. Time windows can be open-ended, and specify only “before” **or** “after”, or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} When both a before and an after time are included the transaction occurred at some point within that time window. diff --git a/content/en/platform/corda/4.11/enterprise/key-concepts-transactions.md b/content/en/platform/corda/4.11/enterprise/key-concepts-transactions.md index c102fcebe06..04d95a8740b 100644 --- a/content/en/platform/corda/4.11/enterprise/key-concepts-transactions.md +++ b/content/en/platform/corda/4.11/enterprise/key-concepts-transactions.md @@ -37,7 +37,7 @@ Every [state]({{< relref "key-concepts-states.md" >}}) is *immutable*—it can't Here is an example of a transaction with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type. Transactions can: * Include different types of states representing multiple financial instruments, such as cash or bonds. @@ -65,21 +65,21 @@ Input state references consist of: You can see how this works in this example transaction: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} ## Committing transactions to the ledger Initially, a transaction is only a proposal to update the ledger. It represents the future state of the ledger desired by the transaction builders. -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To be committed to the ledger, the transaction must receive signatures from all the *required signers*. Each required signer appends their signature to the transaction to approve the proposal. -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If the transaction gathers the required signatures, it is committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions. @@ -121,7 +121,7 @@ For example, suppose Alice uses $5 cash to pay off $5 of an IOU with Bob. This transaction contains a *settlement command* which reduces the amount outstanding on the IOU, and a *payment command* which changes the ownership of $5 from Alice to Bob. It also has two supporting attachments, and is notarized by `NotaryClusterA` if the notary pool receives it within the specified time window: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -145,7 +145,7 @@ listed in the commands, you get the list of the transaction’s required signers This situation would look like this: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/platform/corda/4.11/enterprise/key-concepts-vault.md b/content/en/platform/corda/4.11/enterprise/key-concepts-vault.md index 01b5e696d06..24d7695db03 100644 --- a/content/en/platform/corda/4.11/enterprise/key-concepts-vault.md +++ b/content/en/platform/corda/4.11/enterprise/key-concepts-vault.md @@ -46,7 +46,7 @@ The vault supports the management of data in both authoritative **on-ledger** fo This diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} You can see: diff --git a/content/en/platform/corda/4.11/enterprise/network-builder.md b/content/en/platform/corda/4.11/enterprise/network-builder.md index 6edf6394b3f..9c8b010a9d0 100644 --- a/content/en/platform/corda/4.11/enterprise/network-builder.md +++ b/content/en/platform/corda/4.11/enterprise/network-builder.md @@ -21,7 +21,7 @@ title: Corda Network Builder The Corda Network Builder is a tool for building Corda networks for testing purposes. It leverages Docker and containers to abstract the complexity of managing a distributed network away from the user. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} The network you build will either be made up of local `Docker` nodes *or* of nodes spread across Azure containers. For each node a separate Docker image is built based on [corda/corda-zulu-java1.8-4.4](https://hub.docker.com/r/corda/corda-zulu-java1.8-4.4). diff --git a/content/en/platform/corda/4.11/enterprise/network/cipher-suites.md b/content/en/platform/corda/4.11/enterprise/network/cipher-suites.md index ac26ed34d5c..74bf6c62a83 100644 --- a/content/en/platform/corda/4.11/enterprise/network/cipher-suites.md +++ b/content/en/platform/corda/4.11/enterprise/network/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates]({{< relref "permissioning.md" >}})): -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/platform/corda/4.11/enterprise/network/permissioning.md b/content/en/platform/corda/4.11/enterprise/network/permissioning.md index df7acb84276..489d7894042 100644 --- a/content/en/platform/corda/4.11/enterprise/network/permissioning.md +++ b/content/en/platform/corda/4.11/enterprise/network/permissioning.md @@ -42,7 +42,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/platform/corda/4.11/enterprise/node/collaborative-recovery/collaborative-recovery-121/deployment-and-operations.md b/content/en/platform/corda/4.11/enterprise/node/collaborative-recovery/collaborative-recovery-121/deployment-and-operations.md index a784c28b9be..d8051161cb4 100644 --- a/content/en/platform/corda/4.11/enterprise/node/collaborative-recovery/collaborative-recovery-121/deployment-and-operations.md +++ b/content/en/platform/corda/4.11/enterprise/node/collaborative-recovery/collaborative-recovery-121/deployment-and-operations.md @@ -90,7 +90,7 @@ The space complexities are outlined below: You can see a suggested high-level, disaster recovery setup in the diagram below. -{{< figure alt="Suggested Disaster Recovery Setup" width=80% zoom="../../../resources/collaborative-recovery/dr-setup.png" >}} +{{< figure alt="Suggested Disaster Recovery Setup" width=80% src="../../../resources/collaborative-recovery/dr-setup.png" >}} The exact setup you choose is likely to be influenced by your organisation and business requirements, but the key points are: diff --git a/content/en/platform/corda/4.11/enterprise/node/collaborative-recovery/collaborative-recovery-121/introduction-cr.md b/content/en/platform/corda/4.11/enterprise/node/collaborative-recovery/collaborative-recovery-121/introduction-cr.md index 2c774f5b9a4..705d2a6e075 100644 --- a/content/en/platform/corda/4.11/enterprise/node/collaborative-recovery/collaborative-recovery-121/introduction-cr.md +++ b/content/en/platform/corda/4.11/enterprise/node/collaborative-recovery/collaborative-recovery-121/introduction-cr.md @@ -158,7 +158,7 @@ inbound / outbound reconciliations and also supports different throttling techni A high-level, peer-to-peer reconciliation flow is depicted in the diagram below. **LedgerSync** can run multiple reconciliations concurrently, up to the limit configured by the user. -{{< figure alt="Peer-to-Peer Reconciliation Flow" width=80% zoom="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} +{{< figure alt="Peer-to-Peer Reconciliation Flow" width=80% src="../../../resources/collaborative-recovery/ledger-sync-flow.png" >}} ### LedgerRecover @@ -181,7 +181,7 @@ supports different types of throttling to prevent accidental abuse of the functi A high-level, peer-to-peer automatic recovery flow is depicted in the diagram below. -{{< figure alt="Peer-to-Peer Automatic Recovery Flow" width=80% zoom="../../resources/collaborative-recovery/automatic-ledger-recover-flow.png" >}} +{{< figure alt="Peer-to-Peer Automatic Recovery Flow" width=80% src="../../../resources/collaborative-recovery/automatic-ledger-recover-flow.png" >}} {{< attention >}} Even though the recovery flow contains the word "automatic" in its name, it can only be started manually. @@ -200,7 +200,7 @@ the import has been stopped halfway through. A high-level, peer-to-peer manual recovery flow is depicted in the diagram below. -{{< figure alt="Peer-to-Peer Manual Recovery Flow" width=80% zoom="../../resources/collaborative-recovery/manual-ledger-recover-flow.png" >}} +{{< figure alt="Peer-to-Peer Manual Recovery Flow" width=80% src="../../../resources/collaborative-recovery/manual-ledger-recover-flow.png" >}} ### Supported disaster recovery scenarios diff --git a/content/en/platform/corda/4.11/enterprise/node/collaborative-recovery/collaborative-recovery-121/ledger-sync.md b/content/en/platform/corda/4.11/enterprise/node/collaborative-recovery/collaborative-recovery-121/ledger-sync.md index 065488db55e..9a53d6330fb 100644 --- a/content/en/platform/corda/4.11/enterprise/node/collaborative-recovery/collaborative-recovery-121/ledger-sync.md +++ b/content/en/platform/corda/4.11/enterprise/node/collaborative-recovery/collaborative-recovery-121/ledger-sync.md @@ -28,7 +28,7 @@ All reconciliations are added to a bounded execution pool, which is configurable This means the node that requested the reconciliation will be notified if the responding node has transactions that the requesting node does not. The responding node will not be notified if the requesting node has transactions that the responding node does not. -{{< figure alt="LedgerSync Flow" width=80% zoom="../../../resources/collaborative-recovery/ledger-sync-flow.png" >}} +{{< figure alt="LedgerSync Flow" width=80% src="../../../resources/collaborative-recovery/ledger-sync-flow.png" >}} ### Integration with Archiving diff --git a/content/en/platform/corda/4.11/enterprise/node/component-topology.md b/content/en/platform/corda/4.11/enterprise/node/component-topology.md index 09dee827c4e..32bdc8891e0 100644 --- a/content/en/platform/corda/4.11/enterprise/node/component-topology.md +++ b/content/en/platform/corda/4.11/enterprise/node/component-topology.md @@ -33,7 +33,7 @@ The key node components and services are: * The Corda firewall -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" figcaption="Node internal architecture.">}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" figcaption="Node internal architecture.">}} ### CorDapps @@ -83,14 +83,14 @@ Nodes communicate with other nodes using asynchronous AMQP/TLS 1.2 protocols. HT Nodes communicate with client applications using RPC calls. -{{< figure alt="overview" width=80% zoom="../resources/overview.png" >}} +{{< figure alt="overview" width=80% src="../resources/overview.png" >}} ## Typical node deployments In most cases, nodes are deployed with this architecture: -{{< figure alt="nodebridgefloat nbrs" width=80% zoom="../resources/nodebridgefloat_nbrs.png" figcaption="A typical node deployment.">}} +{{< figure alt="nodebridgefloat nbrs" width=80% src="../resources/nodebridgefloat_nbrs.png" figcaption="A typical node deployment.">}} Most production deployments of Corda Enterprise include nodes, vaults, and firewalls. diff --git a/content/en/platform/corda/4.11/enterprise/node/corda-firewall-component.md b/content/en/platform/corda/4.11/enterprise/node/corda-firewall-component.md index d3a30b8c4e3..b8a63749188 100644 --- a/content/en/platform/corda/4.11/enterprise/node/corda-firewall-component.md +++ b/content/en/platform/corda/4.11/enterprise/node/corda-firewall-component.md @@ -140,7 +140,7 @@ Artemis with the node as TLS endpoint and to have the outgoing packets use the i Typically this should only be used for easy development, or for organisations evaluating on Open Source Corda, where this is the only available option: -{{< figure alt="node embedded bridge" width=80% zoom="/en/images/node_embedded_bridge.png" >}} +{{< figure alt="node embedded bridge" width=80% src="/en/images/node_embedded_bridge.png" >}} ### Node + Combined Bridge/Float (no DMZ) @@ -170,7 +170,7 @@ Then configure an all-in-one bridge to point at this node’s `messagingServerAd {{< /note >}} -{{< figure alt="simple bridge" width=80% zoom="/en/images/simple_bridge.png" >}} +{{< figure alt="simple bridge" width=80% src="/en/images/simple_bridge.png" >}} #### node.conf @@ -238,7 +238,7 @@ key, the tunnel link should use a private set of link specific keys and certific dynamically with the official TLS key when activated via the tunnel and this key will never be stored in the DMZ: {{< /note >}} -{{< figure alt="node bridge float" width=80% zoom="/en/images/node_bridge_float.png" >}} +{{< figure alt="node bridge float" width=80% src="/en/images/node_bridge_float.png" >}} #### node.conf @@ -326,7 +326,7 @@ Some organisations require dynamic outgoing connections to operate via a SOCKS p by adding extra information to the `outboundConfig` section of the bridge process. A simplified example deployment is shown here to highlight the option: -{{< figure alt="socks proxy" width=80% zoom="/en/images/socks_proxy.png" >}} +{{< figure alt="socks proxy" width=80% src="/en/images/socks_proxy.png" >}} #### node.conf @@ -426,7 +426,7 @@ Highlighted in the diagram is the addition of the `haConfig` section to point at addresses in the `alternateArtemisAddresses` to allow node failover and in the `floatAddresses` to point at a pool of DMZ float processes. -{{< figure alt="ha nodes" width=80% zoom="/en/images/ha_nodes.png" >}} +{{< figure alt="ha nodes" width=80% src="/en/images/ha_nodes.png" >}} #### node.conf @@ -563,7 +563,7 @@ It is possible to allow two or more Corda nodes (HA and/or non-HA) handle outgoi an external Artemis messaging broker which can be easily configured using the ha-tool. For more information, please see HA Utilities. While this example is the simplest deployment possible with a shared bridge, any other configuration previously presented can be created. -{{< figure alt="multiple nodes no ha" width=80% zoom="/en/images/multiple_nodes_no_ha.png" >}} +{{< figure alt="multiple nodes no ha" width=80% src="/en/images/multiple_nodes_no_ha.png" >}} #### bank-a-node.conf diff --git a/content/en/platform/corda/4.11/enterprise/node/corda-firewall-configuration-file.md b/content/en/platform/corda/4.11/enterprise/node/corda-firewall-configuration-file.md index fae993e5bfc..5565574a762 100644 --- a/content/en/platform/corda/4.11/enterprise/node/corda-firewall-configuration-file.md +++ b/content/en/platform/corda/4.11/enterprise/node/corda-firewall-configuration-file.md @@ -132,14 +132,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -152,7 +152,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/platform/corda/4.11/enterprise/node/deploy/env-prod-test.md b/content/en/platform/corda/4.11/enterprise/node/deploy/env-prod-test.md index 58c3a40fce7..5544de545c7 100644 --- a/content/en/platform/corda/4.11/enterprise/node/deploy/env-prod-test.md +++ b/content/en/platform/corda/4.11/enterprise/node/deploy/env-prod-test.md @@ -33,12 +33,12 @@ There are alternative approaches to how these components are deployed. For the p When deploying Corda Enterprise in a testing environment the Node, Bridge, and Float components should be deployed in a non-HA configuration as shown in the following diagram. -{{< figure alt="nonha" width=80% zoom="../../resources/nonha.png" >}} +{{< figure alt="nonha" width=80% src="../../resources/nonha.png" >}} When deploying Corda Enterprise in a production environment, the Node, Bridge, and Float components should be deployed in a high-availability configuration. -{{< figure alt="ha" width=80% zoom="../../resources/ha.png" >}} +{{< figure alt="ha" width=80% src="../../resources/ha.png" >}} ### Deployment details @@ -205,7 +205,7 @@ This is a sample `node.conf` which details a configuration connecting to a Corda In a bank environment there will typically be several layers of security protecting the firms data. -{{< figure alt="cordarch" width=80% zoom="../../resources/cordarch.png" >}} +{{< figure alt="cordarch" width=80% src="../../resources/cordarch.png" >}} *Network Authentication* @@ -219,7 +219,7 @@ In a bank environment there will typically be several layers of security protect * Corda PKI Authentication issued by Corda Network can link the Node and Bridge i.e. the red keys indicated below truststore and sslkeystore * Local PKI Authentication issued by separate CA will link the Bridge and Float i.e the purple keys indicated below trust and Bridge. -{{< figure alt="firewallpki" width=80% zoom="../../resources/firewallpki.png" >}} +{{< figure alt="firewallpki" width=80% src="../../resources/firewallpki.png" >}} The key thing is to look at this from the perspective of a bank implementing these Corda and Local PKI keys. @@ -374,7 +374,7 @@ Administrative logins with the Corda node happen via ssh whose port is configure The following image may be helpful in ensuring alignment between the Node, Bridge and Float configuration files. -{{< figure alt="CordaFirewallConfigAlign" width=80% zoom="../../resources/CordaFirewallConfigAlign.png" >}} +{{< figure alt="CordaFirewallConfigAlign" width=80% src="../../resources/CordaFirewallConfigAlign.png" >}} {{< note >}} **p2pAddress** reflects the **publicly accessible address**, which may or may not be the Float inboundConfig.listeningAddress. If there is an internet firewall configured in front of the Float then ask the Network Administrator for the public address that routes to the Float’s **listeningAddress**, and use that public address for your **p2pAddress**. diff --git a/content/en/platform/corda/4.11/enterprise/node/deploy/hot-cold-deployment.md b/content/en/platform/corda/4.11/enterprise/node/deploy/hot-cold-deployment.md index f22e6ce2487..206888666ac 100644 --- a/content/en/platform/corda/4.11/enterprise/node/deploy/hot-cold-deployment.md +++ b/content/en/platform/corda/4.11/enterprise/node/deploy/hot-cold-deployment.md @@ -36,7 +36,7 @@ resources for both **Microsoft Azure** and **Amazon Web Services**. The image be result from following the guide. There will be two Corda Enterprise nodes, one active and the other inactive. Each node will represent the same legal identity inside the Corda network. Both will share a database and a network file system. -{{< figure alt="hot cold" width=80% zoom="../../resources/hot-cold.png" >}} +{{< figure alt="hot cold" width=80% src="../../resources/hot-cold.png" >}} ## Configuring the load balancer diff --git a/content/en/platform/corda/4.11/enterprise/node/operating/node-administration.md b/content/en/platform/corda/4.11/enterprise/node/operating/node-administration.md index 0cad022a920..7c26be3c589 100644 --- a/content/en/platform/corda/4.11/enterprise/node/operating/node-administration.md +++ b/content/en/platform/corda/4.11/enterprise/node/operating/node-administration.md @@ -245,7 +245,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ### Monitoring via Graphite diff --git a/content/en/platform/corda/4.11/enterprise/node/operating/node-database-tables.md b/content/en/platform/corda/4.11/enterprise/node/operating/node-database-tables.md index 621b5ee1fed..23eb31940b9 100644 --- a/content/en/platform/corda/4.11/enterprise/node/operating/node-database-tables.md +++ b/content/en/platform/corda/4.11/enterprise/node/operating/node-database-tables.md @@ -42,7 +42,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more in [Network map]({{< relref "../../network/network-map.md" >}}). -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -170,7 +170,7 @@ Read more in [Ledger]({{< relref "../../key-concepts-ledger.md" >}}). ### Attachments Read more in [Working with attachments]({{< relref "../../get-started/tutorials/supplementary-tutorials/tutorial-attachments.md" >}}) and [Node services]({{< relref "../../node-services.md" >}}). -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -518,7 +518,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -547,7 +547,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/platform/corda/4.11/enterprise/node/pki-guide.md b/content/en/platform/corda/4.11/enterprise/node/pki-guide.md index 4fa76829584..db504618ee9 100644 --- a/content/en/platform/corda/4.11/enterprise/node/pki-guide.md +++ b/content/en/platform/corda/4.11/enterprise/node/pki-guide.md @@ -54,7 +54,7 @@ as they root to the same certificate. Other than that, Corda nodes stay agnostic to the certificate hierarchy (in particular the depth of the certificate hierarchy tree). -{{< figure alt="hierarchy agnostic" width=80% zoom="../resources/hierarchy-agnostic.png" >}} +{{< figure alt="hierarchy agnostic" width=80% src="../resources/hierarchy-agnostic.png" >}} At the time of writing this document, the Corda Network assumes the certificate hierarchy that can be found in the [Certificate hierarchy guide]({{< relref "../network/permissioning.md#certificate-hierarchy" >}}). @@ -69,7 +69,7 @@ The network operator is responsible for certificate issuance and maintenance for at the Identity Manager and Network Map certificates. The rest of the certificate chain (i.e. every certificate below the Identity Manager certificate) falls into node operator responsibility. -{{< figure alt="tls hierarchy" width=80% zoom="../resources/tls-hierarchy.png" >}} +{{< figure alt="tls hierarchy" width=80% src="../resources/tls-hierarchy.png" >}} The certificate revocation list verification applies to the entire chain. This means that every certificate in the chain is going to be validated against the corresponding certificate revocation list during the SSL handshake. Consequently, this means that a node operator is expected to provide and maintain the certificate revocation list for the Node CA. @@ -87,7 +87,7 @@ During the certificate revocation list validation process the trust store is con As an example, let us consider the following certificate hierarchy: -{{< figure alt="example hierarchy" width=80% zoom="../resources/example-hierarchy.png" >}} +{{< figure alt="example hierarchy" width=80% src="../resources/example-hierarchy.png" >}} The certificate hierarchy presented above is currently (as of the time of writing this document) used in the Corda Network. It follows practices applicable for certificate authorities providing a balance between security and simplicity of usage. In this scenario, a network operator wants to create a CA hierarchy where the self-signed Root CA issues a certificate for the Subordinate CA which in turn issues diff --git a/content/en/platform/corda/4.11/enterprise/notary-healthcheck.md b/content/en/platform/corda/4.11/enterprise/notary-healthcheck.md index 36d4608185a..29adababd68 100644 --- a/content/en/platform/corda/4.11/enterprise/notary-healthcheck.md +++ b/content/en/platform/corda/4.11/enterprise/notary-healthcheck.md @@ -173,4 +173,4 @@ monitor notary health via a dashboard or hook up an alerter. As an example, this view on a failing notary check. Note the metrics for *success*, *fail*, *inflight*, and *maxinflightTime* for the notary service and the cluster members on the left hand side. -{{< figure alt="hawtio healthcheck" width=80% zoom="./resources/hawtio-healthcheck.png" >}} +{{< figure alt="hawtio healthcheck" width=80% src="./resources/hawtio-healthcheck.png" >}} diff --git a/content/en/platform/corda/4.11/enterprise/notary/backup-restore.md b/content/en/platform/corda/4.11/enterprise/notary/backup-restore.md index 3ac78c75690..d0606ea0826 100644 --- a/content/en/platform/corda/4.11/enterprise/notary/backup-restore.md +++ b/content/en/platform/corda/4.11/enterprise/notary/backup-restore.md @@ -29,7 +29,7 @@ Additionally, it is critical to have a backup of the Notary Service identity pri The following diagram highlights in blue which storage components should be backed up. -{{< figure alt="storage components" width=80% zoom="../resources/storage-components.png" >}} +{{< figure alt="storage components" width=80% src="../resources/storage-components.png" >}} Note that for regular nodes it is very important to back up the Messaging Broker (Artemis) folder and the local Database, but for HA notary nodes that are purely used for notarisation purposes that is not needed. To summarise: diff --git a/content/en/platform/corda/4.11/enterprise/notary/ha-notary-service-overview.md b/content/en/platform/corda/4.11/enterprise/notary/ha-notary-service-overview.md index 004a03e79ad..cd9ac442084 100644 --- a/content/en/platform/corda/4.11/enterprise/notary/ha-notary-service-overview.md +++ b/content/en/platform/corda/4.11/enterprise/notary/ha-notary-service-overview.md @@ -60,7 +60,7 @@ database to store its node state (e.g. its identity information). We can visualise this set-up as follows, with the regular Corda nodes in green, the Corda notary worker nodes in red, and the standard node databases and notary state database replicas in blue. -{{< figure alt="ha notary overview2" width=80% zoom="../resources/ha-notary-overview2.png" >}} +{{< figure alt="ha notary overview2" width=80% src="../resources/ha-notary-overview2.png" >}} Nodes requesting notarisation from a highly-available notary will connect to the notary workers in round-robin fashion. Provided there are multiple notary workers and the notary state database is configured to be highly-available, the overall notary service @@ -73,7 +73,7 @@ In production, R3 recommends running five or more replicas in the notary state d If desired, you can choose to run each database server and its Corda notary worker on the same machine: -{{< figure alt="ha notary colocated" width=80% zoom="../resources/ha-notary-colocated.png" >}} +{{< figure alt="ha notary colocated" width=80% src="../resources/ha-notary-colocated.png" >}} ## Notary configuration diff --git a/content/en/platform/corda/4.11/enterprise/notary/hsm-support.md b/content/en/platform/corda/4.11/enterprise/notary/hsm-support.md index 62a084e06cc..508d3c06b4b 100644 --- a/content/en/platform/corda/4.11/enterprise/notary/hsm-support.md +++ b/content/en/platform/corda/4.11/enterprise/notary/hsm-support.md @@ -14,7 +14,7 @@ weight: 3 ## Overview -{{< figure alt="hsm support" width=80% zoom="../resources/hsm-support.png" >}} +{{< figure alt="hsm support" width=80% src="../resources/hsm-support.png" >}} Two notary workers and their relevant cryptographic keys used for P2P messaging and transaction signing. The red rectangles represent the Corda notary worker services. The distinct identity keys are represented by rectangles in green and yellow and the shared key of the notary service identity is drawn in blue. Their cryptographic keys are held in a single HSM. diff --git a/content/en/platform/corda/4.11/enterprise/operations/deployment/firewall-deployment.md b/content/en/platform/corda/4.11/enterprise/operations/deployment/firewall-deployment.md index 46573cd6de7..d1cfb19fa86 100644 --- a/content/en/platform/corda/4.11/enterprise/operations/deployment/firewall-deployment.md +++ b/content/en/platform/corda/4.11/enterprise/operations/deployment/firewall-deployment.md @@ -129,14 +129,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -149,7 +149,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/platform/corda/4.11/enterprise/performance-testing/introduction.md b/content/en/platform/corda/4.11/enterprise/performance-testing/introduction.md index b906403570b..05adb023612 100644 --- a/content/en/platform/corda/4.11/enterprise/performance-testing/introduction.md +++ b/content/en/platform/corda/4.11/enterprise/performance-testing/introduction.md @@ -110,7 +110,7 @@ The driving app sits outside the network and connects to the JMeter servers thro measuring the throughput of a node, the test definition instructs all JMeter servers to open RPC connections to one node, thus saturating the RPC handler and driving the node as hard as possible. The test might invoke a flow that can be completed locally (for example, cash issuance) or it might require exchanging P2P messages with other nodes (for example, cash payment). -{{< figure alt="jmeter network overview" width=80% zoom="../resources/jmeter-network-overview.png" >}} +{{< figure alt="jmeter network overview" width=80% src="../resources/jmeter-network-overview.png" >}} ## Performance tests diff --git a/content/en/platform/corda/4.11/enterprise/performance-testing/jmeter-samplers.md b/content/en/platform/corda/4.11/enterprise/performance-testing/jmeter-samplers.md index 6640167f043..c5eec9ce900 100644 --- a/content/en/platform/corda/4.11/enterprise/performance-testing/jmeter-samplers.md +++ b/content/en/platform/corda/4.11/enterprise/performance-testing/jmeter-samplers.md @@ -66,7 +66,7 @@ server, not the client machine. * `minimumNodePlatformVersion`: the minimum platform version that the JMeter client will require from the Corda nodes. It defaults to 4, which can be used to test with Corda 4.0 nodes or later. * `username`: the RPC user name of the Corda node. * `password`: the RPC password of the Corda node. -{{< figure alt="empty flow sampler" width=80% zoom="../resources/empty-flow-sampler.png" >}} +{{< figure alt="empty flow sampler" width=80% src="../resources/empty-flow-sampler.png" >}} * `CashIssueSampler`: this sampler client has the class name `com.r3.corda.jmeter.CashIssueSampler` and starts the flow `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueFlow`. This flow self-issues 1.1 billion cash tokens on the node it is running on, and stores it in the vault. In addition to the common properties described for `EmptyFlowSampler` above, this sampler client also requires: * `notaryName`: the X500 name of the notary that is acceptable to transfer cash tokens issued via this sampler. Issuing tokens does not need to be notarised, and therefore invoking this sampler does not create traffic to the notary. However, the notary is stored as part of the cash state and must be valid to do anything else with the cash state, therefore this sampler checks the notary identity against the network parameters of the node. * `CashIssueAndPaySampler`: this sampler client has the classname `com.r3.corda.jmeter.CashIssueAndPaySampler` and, depending on its parameters, it can start either of these flows - `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndPaymentFlow` or `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndpaymentNoSelection`. Either way it issues 2 million dollars in tokens and then transfers the sum to a configurable other node, thus invoking the full vault access, peer-to-peer communication and notarisation cycle. In addition to the parameters required for `CashIssueSampler`, this sampler also requires: diff --git a/content/en/platform/corda/4.11/enterprise/performance-testing/jmeter-testplans.md b/content/en/platform/corda/4.11/enterprise/performance-testing/jmeter-testplans.md index 37b8c68a81a..84e36721999 100644 --- a/content/en/platform/corda/4.11/enterprise/performance-testing/jmeter-testplans.md +++ b/content/en/platform/corda/4.11/enterprise/performance-testing/jmeter-testplans.md @@ -25,12 +25,12 @@ The testplan is a hierarchy of configuration elements. The only elements used in *Variables*, *Thread Groups*, *Samplers* and *Listeners*. Rather than creating a new testplan from scratch, it might a good idea to take a copy of one of the provided example test plans and modify that. -{{< figure alt="jmeter testplan" width=80% zoom="../resources/jmeter-testplan.png" >}} +{{< figure alt="jmeter testplan" width=80% src="../resources/jmeter-testplan.png" >}} A variables element defines key/value pairs that can be used in all following following elements instead of string literals. They can be referenced by using a `$` sign and curly braces, e.g. `${varName}`. -{{< figure alt="variables" width=80% zoom="../resources/variables.png" >}} +{{< figure alt="variables" width=80% src="../resources/variables.png" >}} A thread group collects a set of actions that form one step in the test plan. All elements within a thread group diff --git a/content/en/platform/corda/4.11/enterprise/performance-testing/performance-results.md b/content/en/platform/corda/4.11/enterprise/performance-testing/performance-results.md index b7b27294880..9fcc3de7952 100644 --- a/content/en/platform/corda/4.11/enterprise/performance-testing/performance-results.md +++ b/content/en/platform/corda/4.11/enterprise/performance-testing/performance-results.md @@ -40,7 +40,7 @@ the time of Corda Enterprise Edition 4 release). This is with each node running running **Microsoft SQL Server**. Similar results were obtained against the other supported databases. -{{< figure alt="ce4 comparison chart" width=80% zoom="/en/images/ce4-comparison-chart.png" >}} +{{< figure alt="ce4 comparison chart" width=80% src="/en/images/ce4-comparison-chart.png" >}} Figure 1 @@ -52,7 +52,7 @@ varies with the number of those payments combined together. This can be useful be a technique for even greater throughput. -{{< figure alt="states per second" width=80% zoom="/en/images/states-per-second.png" >}} +{{< figure alt="states per second" width=80% src="/en/images/states-per-second.png" >}} Figure 2 @@ -65,7 +65,7 @@ of Figure 3 were achieved using Corda Enterprise 3.0 on **Microsoft Azure** virt with minimal latency between the node VM and the database server VM. -{{< figure alt="comparison chart" width=80% zoom="/en/images/comparison-chart.png" >}} +{{< figure alt="comparison chart" width=80% src="/en/images/comparison-chart.png" >}} Figure 3 @@ -303,7 +303,7 @@ All these machines were 24 core (48 hyper-threads), based on 2x Intel Xeon E5-26 The first test performed was focused on the latency aspect. Load was generated from a single client initialised in a machine that was separate from the ones hosting the Corda nodes and their databases. The load consisted of a pre-defined number of flows (400) that were executed one after the other sequentially. Each one of those flows was initiated on the central exchange node, which was responsible for collecting signatures from all the parties involved and for finalising the transaction. Each of those flows performed a swap of two states between every pair of nodes, thus leading to a Corda transaction with 10 input and 10 output states. During the test setup, the necessary amount of states was initially issued and each one of those states would be swapped once during the test. In order to also measure the impact of transaction resolution, during the test setup each of these states was transferred bilaterally between the nodes in each pair ten times, thus generating a backchain of depth 10. This meant that during every Corda transaction, each node would have to resolve the backchain of the states belonging to the other pairs - so each node would have to resolve 80 states (8 nodes x 10 states each). In order to also measure the scaling with regard to the number of nodes, the exact same test was repeated with a varying number of participants, starting from 4 nodes and going up to 10. The test was also repeated three times with Corda Enterprise versions 4.3, 4.4, and 4.5. The goal was to isolate the benefits from bulk transaction resolution, introduced in version 4.4, and parallelised flows (`CollectSignaturesFlow` / `FinalityFlow`), introduced in version 4.5. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average latency of the flow that performed the asset swap in milliseconds. -{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.3 shows an exponential increase in the latency of the flow as the number of nodes that participate in the transaction is increased. This can be attributed to the following two reasons. Firstly, during the tests the exchange node was performing the `CollectSignaturesFlow` and `FinalityFlow` flows sequentially across the involved nodes, so the more nodes these flows had to iterate over, the more time it took. Secondly, these flows have the capability to trigger the execution of transaction resolution if they identify states for which the node is missing the provenance chain. In Corda Enterprise Edition 4.3, transaction resolution is not performed in bulk - it is performed one state at a time. As a result, every additional node causes a significant amount of extra work to be done. @@ -314,7 +314,7 @@ The main observations from the tests follow below: The second test was focused on the throughput aspect. Load was generated from multiple clients initialised on the machines that were hosting the Corda nodes, which were acting as JMeter servers orchestrated by a JMeter client running on a separate machine. The goal was to saturate the participating Corda nodes and to prevent the single client from becoming the bottleneck. During the test setup, each client issued one state to every node. Each client was then performing one flow at a time, swapping these states between the participating nodes. No backchain was generated as part of this test. As a result, the test was executed only between Corda Enterprise Edition 4.3 and Corda Enterprise Edition 4.5, and with a varying number of nodes ranging from 2 up to 10. Each of the machines driving the load was using 120 concurrent clients, which summed up to 480 concurrent clients in total. Additional measurements were performed with a varying number of clients, in order to ensure that this was the optimal number of clients to saturate the nodes without overloading them. Since the throughput was different depending on the number of participating nodes, the total number of requests was also adjusted accordingly in order to get roughly the same total duration of approximately 20 minutes. In all the scenarios, it was confirmed that the nodes had reached a stable state when the test ended. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average throughput measured in the number of flows completed per second. -{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.5 can achieve a significantly higher throughput when compared to Corda Enterprise Edition 4.3. This can be attributed to the following factors: @@ -336,9 +336,9 @@ Five different variations were tested, as follows: The purpose of this last test was to investigate the effects of these options in both throughput and latency because some of these options introduce trade-offs between these two aspects. To this end, the tests described earlier in this analysis were repeated using the variations listed above. For the latency measurements, 10 nodes were used because, thanks to the low load, there was no expectation for any big interference between nodes on the same machine. For the throughput measurements, only 4 nodes were used in order to avoid any interference between nodes on the same machine due to the high load. The results are shown in the diagrams below - the *x* axis contains the variations used, and the *y* axis shows the average throughput and latency achieved with each variation along with error bars indicating the standard deviation. -{{< figure alt="CE 4.5 variants latency comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_latency.png" >}} +{{< figure alt="CE 4.5 variants latency comparison chart" width=80% src="../resources/performance-testing/4-5_variants_latency.png" >}} -{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_throughput.png" >}} +{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% src="../resources/performance-testing/4-5_variants_throughput.png" >}} The main observations from the test are as follows: * Disabling compression leads to lower throughput and higher latency. This is expected because compression introduces a trade-off between CPU and network bandwidth utilisation and in most cases the network would prove to be a bigger bottleneck. diff --git a/content/en/platform/corda/4.11/enterprise/performance-testing/practical-considerations.md b/content/en/platform/corda/4.11/enterprise/performance-testing/practical-considerations.md index a6ec33b1f14..099e2759aa5 100644 --- a/content/en/platform/corda/4.11/enterprise/performance-testing/practical-considerations.md +++ b/content/en/platform/corda/4.11/enterprise/performance-testing/practical-considerations.md @@ -94,7 +94,7 @@ To collect the output of a JMeter performance run, we need to add listeners to t This listener just lists all the runs that have been completed, one run per row, stating the thread name, sampler label, the sample time in milliseconds, the result status and the latency in milliseconds, among other (usually less useful) fields. -{{< figure alt="jmeter results table" width=80% zoom="../resources/jmeter-results-table.png" >}} +{{< figure alt="jmeter results table" width=80% src="../resources/jmeter-results-table.png" >}} This view is particularly useful when trying out any changes (new flow, new sampler, new installation) to see if it is working at all. The potential outcomes are: @@ -123,7 +123,7 @@ This listener aggregates all the runs for each thread group and the whole test p It also allows plotting these statistics in basic charts and to save the results as a csv file. This is what we use for looking at the performance results on a day to day basis. -{{< figure alt="jmeter results aggregate" width=80% zoom="../resources/jmeter-results-aggregate.png" >}} +{{< figure alt="jmeter results aggregate" width=80% src="../resources/jmeter-results-aggregate.png" >}} This listener has one line for each sampler being run as part of the test plan, and a total line summing up/averaging the results for the whole test plan. diff --git a/content/en/platform/corda/4.11/enterprise/performance-testing/r3-performance-runs.md b/content/en/platform/corda/4.11/enterprise/performance-testing/r3-performance-runs.md index 490bbd4663f..cbf669481f1 100644 --- a/content/en/platform/corda/4.11/enterprise/performance-testing/r3-performance-runs.md +++ b/content/en/platform/corda/4.11/enterprise/performance-testing/r3-performance-runs.md @@ -32,7 +32,7 @@ The performance network sits behind a firewall that allows incoming connections within the network can connect to each other on a range of ports (Corda Remote Procedure Call (RPC), Corda peer to peer connection (P2P) and JDBC connections to various database servers are all allowed). -{{< figure alt="performance cluster" width=80% zoom="../resources/performance-cluster.png" >}} +{{< figure alt="performance cluster" width=80% src="../resources/performance-cluster.png" >}} A Corda JMeter server instance is running on all 4 nodes and on the notary server. The JMeter client connects to the JMeter server instances via SSH tunnels. As the JMeter servers run within the firewalled network, they are free to diff --git a/content/en/platform/corda/4.11/enterprise/performance-testing/running-jmeter-corda.md b/content/en/platform/corda/4.11/enterprise/performance-testing/running-jmeter-corda.md index 478fc13fc6d..ad2a2f1df0f 100644 --- a/content/en/platform/corda/4.11/enterprise/performance-testing/running-jmeter-corda.md +++ b/content/en/platform/corda/4.11/enterprise/performance-testing/running-jmeter-corda.md @@ -54,7 +54,7 @@ interactively either locally or remotely, and view results. The UI has a set of quickly create or load a testplan, control local or remote test runs, and clear any test results collected so far. The latter is particularly important when looking at averages, as old data might skew the results being looked at. -{{< figure alt="jmeter buttons" width=80% zoom="../resources/jmeter-buttons.png" >}} +{{< figure alt="jmeter buttons" width=80% src="../resources/jmeter-buttons.png" >}} The *clear current view* button only clears the data in the currently viewed output collector - if a test plan has several output listeners defined (as in the example above, we have *Aggregate Graph*, *Graph Results* and *View Results in Table*), any collector not currently selected is not affected. *Clear all data* will clear the results from all collectors. diff --git a/content/en/platform/corda/4.11/enterprise/two-phase-finality.md b/content/en/platform/corda/4.11/enterprise/two-phase-finality.md index 26f90820fd1..f865ceea986 100644 --- a/content/en/platform/corda/4.11/enterprise/two-phase-finality.md +++ b/content/en/platform/corda/4.11/enterprise/two-phase-finality.md @@ -27,7 +27,7 @@ One or more **receivers** use the built-in flow `ReceiveFinalityFlow` to receive Up until Corda 4.10, the finality flow protocol was implemented using a single pass transaction sharing mechanism as depicted below: -{{< figure alt="Conventional Single Phase Finality Protocol" width=100% zoom="./resources/C4-finality-conventional.png" >}} +{{< figure alt="Conventional Single Phase Finality Protocol" width=100% src="./resources/C4-finality-conventional.png" >}} {{< note >}} * Peers only received the finalized transaction after successful notarization. @@ -48,7 +48,7 @@ To address the shortcomings of the conventional protocol, Two Phase Finality int The following diagram illustrates the Two Phase Finality protocol: -{{< figure alt="Two Phase Finality Protocol" width=100% zoom="./resources/C4-finality-optimized-two-phase-finality.png" >}} +{{< figure alt="Two Phase Finality Protocol" width=100% src="./resources/C4-finality-optimized-two-phase-finality.png" >}} The two primary optimizations used within the protocol are: diff --git a/content/en/platform/corda/4.12/community/api-core-types.md b/content/en/platform/corda/4.12/community/api-core-types.md index fdaf83454a2..5acdf7b229f 100644 --- a/content/en/platform/corda/4.12/community/api-core-types.md +++ b/content/en/platform/corda/4.12/community/api-core-types.md @@ -74,11 +74,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="./resources/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="./resources/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="./resources/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="./resources/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/platform/corda/4.12/community/api-flows.md b/content/en/platform/corda/4.12/community/api-flows.md index 23fef5c1b24..4a95b85066d 100644 --- a/content/en/platform/corda/4.12/community/api-flows.md +++ b/content/en/platform/corda/4.12/community/api-flows.md @@ -91,7 +91,7 @@ The `initiator`: You can visualize the work performed by initiator like this: -{{< figure alt="flow overview" width=80% zoom="./resources/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="./resources/flow-overview.png" >}} ## Responder flow class example diff --git a/content/en/platform/corda/4.12/community/api-states.md b/content/en/platform/corda/4.12/community/api-states.md index 8e9410c88f1..de8249795ca 100644 --- a/content/en/platform/corda/4.12/community/api-states.md +++ b/content/en/platform/corda/4.12/community/api-states.md @@ -68,7 +68,7 @@ common sub-interfaces are `LinearState` and `OwnableState`. You can visualize the hierarchy like this: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/platform/corda/4.12/community/apps/bankinabox/user-interface/how-to.md b/content/en/platform/corda/4.12/community/apps/bankinabox/user-interface/how-to.md index 5ec2374c65c..4dc31d5e159 100644 --- a/content/en/platform/corda/4.12/community/apps/bankinabox/user-interface/how-to.md +++ b/content/en/platform/corda/4.12/community/apps/bankinabox/user-interface/how-to.md @@ -70,7 +70,7 @@ Follow these steps to create a new customer profile. When the customer profile is created, they will not have any accounts - you will have to create them. Learn how under [Creating accounts](#create-a-current-account). {{< /note >}} -{{< figure alt="Create customer profile" width=80% zoom="/en/gifs/create-customer-biab-1.0.gif" >}} +{{< figure alt="Create customer profile" width=80% src="/en/gifs/create-customer-biab-1.0.gif" >}} ### Create a Current account @@ -94,7 +94,7 @@ When the customer profile is created, they will not have any accounts - you will 7. When an account is created, it is in **PENDING** status. This must be changed to **ACTIVE** for a customer to be able to interact with and use the account. See [Change an account status](#change-an-account-status) for more information. -{{< figure alt="Create account" width=80% zoom="/en/gifs/create-current-account-biab-1.0.gif" >}} +{{< figure alt="Create account" width=80% src="/en/gifs/create-current-account-biab-1.0.gif" >}} ### Create a Savings account @@ -140,7 +140,7 @@ An account has three statuses: **PENDING**, **ACTIVE**, and **SUSPENDED**. When If the account needs to be suspended, follow the same steps but select **SUSPENDED**. -{{< figure alt="Set account status" width=80% zoom="/en/gifs/set-account-status-biab-1.0.gif" >}} +{{< figure alt="Set account status" width=80% src="/en/gifs/set-account-status-biab-1.0.gif" >}} ### Assign or revoke a user role @@ -163,7 +163,7 @@ To assign a user role, follow these steps: 5. Click **Revoke**. A message will appear indicating that the user role was assigned successfully. -{{< figure alt="Assign role" width=80% zoom="/en/gifs/assign-a-role-biab-1.0.gif" >}} +{{< figure alt="Assign role" width=80% src="/en/gifs/assign-a-role-biab-1.0.gif" >}} #### Revoke a user role @@ -179,7 +179,7 @@ To revoke a user role, follow these steps: 5. Click **Save**. A message will appear indicating that the user role was revoked successfully. -{{< figure alt="Revoke role" width=80% zoom="/en/gifs/revoke-role-biab-1.0.gif" >}} +{{< figure alt="Revoke role" width=80% src="/en/gifs/revoke-role-biab-1.0.gif" >}} ### Issue a loan @@ -195,7 +195,7 @@ Once the account has been set to **ACTIVE**, you will have the ability to issue A loan account is created when a loan has been issued successfully. -{{< figure alt="Issue loan" width=80% zoom="/en/gifs/issue-loan-biab-1.0.gif" >}} +{{< figure alt="Issue loan" width=80% src="/en/gifs/issue-loan-biab-1.0.gif" >}} ### Approve overdrafts @@ -215,7 +215,7 @@ To approve an overdraft, follow these steps. Overdrafts can be approved whether the account is **PENDING**, **ACTIVE**, or **SUSPENDED**. {{< /note >}} -{{< figure alt="Approve overdraft" width=80% zoom="/en/gifs/approve-overdraft-biab-1.0.gif" >}} +{{< figure alt="Approve overdraft" width=80% src="/en/gifs/approve-overdraft-biab-1.0.gif" >}} ### Deposit money to an account @@ -230,7 +230,7 @@ Follow these steps to deposit money to a customer account. 4. Click **Save**. You will receive a message indicating that the deposit was successful. -{{< figure alt="Deposit" width=80% zoom="/en/gifs/deposit-biab-1.0.gif" >}} +{{< figure alt="Deposit" width=80% src="/en/gifs/deposit-biab-1.0.gif" >}} ### Register as a user on Bank in a Box @@ -251,7 +251,7 @@ You must be registered as a **Customer** or **Admin** on Bank in a Box to perfor 5. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update customer profile @@ -284,7 +284,7 @@ An **Admin user** can set an account's **Withdrawal daily limit** or **Transfer 2. Click **Save** when you have entered the desired limits. A message will appear indicating that the limits have been saved successfully. -{{< figure alt="Set withdrawal and transfer limits - admin" width=80% zoom="/en/gifs/set-limits-admin-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - admin" width=80% src="/en/gifs/set-limits-admin-biab-1.0.gif" >}} ## Customer tasks @@ -309,12 +309,12 @@ Follow these steps to create a new intrabank payment. 6. Click **Save**. You will receive a notification indicating that the payment was created successfully. You will also receive notifications indicating any changes in your account balances. -{{< figure alt="Create intrabank payment" width=80% zoom="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} +{{< figure alt="Create intrabank payment" width=80% src="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} After making a payment, you can view the details of this transaction on the Transactions screen. -{{< figure alt="View transaction" width="800" width=80% zoom="/en/gifs/view-transaction-biab-1.0.gif" >}} +{{< figure alt="View transaction" width="800" width=80% src="/en/gifs/view-transaction-biab-1.0.gif" >}} ### Create a recurring payment @@ -338,7 +338,7 @@ Follow these steps to create a recurring payment: 3. You will be taken back to the **Recurring payments screen** where you will receive a message indicating that the recurring payment was created successfully. -{{< figure alt="Recurring payment" width=80% zoom="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} +{{< figure alt="Recurring payment" width=80% src="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} {{< note >}} This payment will not appear on the **Recurring payments screen** until the first iteration has occurred. @@ -367,7 +367,7 @@ You must be registered as a Customer or Admin on Bank in a Box to perform tasks. 7. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update a customer profile @@ -406,4 +406,4 @@ To set these limits as a **Customer**, follow these steps. 4. Click **Save**. You will be taken back to the Account page where you will receive a message indicating that the limits have been updated successfully. -{{< figure alt="Set withdrawal and transfer limits - customer" width=80% zoom="/en/gifs/set-limits-customer-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - customer" width=80% src="/en/gifs/set-limits-customer-biab-1.0.gif" >}} diff --git a/content/en/platform/corda/4.12/community/building-the-docs.md b/content/en/platform/corda/4.12/community/building-the-docs.md index 51d1ce2a87b..540cbf48e0d 100644 --- a/content/en/platform/corda/4.12/community/building-the-docs.md +++ b/content/en/platform/corda/4.12/community/building-the-docs.md @@ -76,7 +76,7 @@ Or if you want to use Docker: As a result, there will be an extra icon in the title bar of your local docs site, which should open the current page in Visual Studio Code: -{{< figure alt="Visual Studio Code" width=80% zoom="/en/images/hugo-vscode-page-edit.png" >}} +{{< figure alt="Visual Studio Code" width=80% src="/en/images/hugo-vscode-page-edit.png" >}} ## Edit web pages directly in Atom diff --git a/content/en/platform/corda/4.12/community/cipher-suites.md b/content/en/platform/corda/4.12/community/cipher-suites.md index fcaa3cd4587..cadd35b2948 100644 --- a/content/en/platform/corda/4.12/community/cipher-suites.md +++ b/content/en/platform/corda/4.12/community/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates]({{< relref "permissioning.md" >}})): -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/platform/corda/4.12/community/comm-upgrade-guide.md b/content/en/platform/corda/4.12/community/comm-upgrade-guide.md index d9eca6873ad..531a1ae8521 100644 --- a/content/en/platform/corda/4.12/community/comm-upgrade-guide.md +++ b/content/en/platform/corda/4.12/community/comm-upgrade-guide.md @@ -45,7 +45,7 @@ The different colors in the diagram indicate the elements used in each version. The Corda 4.11 transaction verifier has also been preserved in an external process to allow Corda 4.11 transactions to be verified by Corda 4.12. -{{< figure alt="Corda 4.12 vs Corda 4.11" width=75% height=75% zoom="resources/corda412vs411.png" figcaption="Corda 4.12 vs Corda 4.11">}} +{{< figure alt="Corda 4.12 vs Corda 4.11" width=75% height=75% src="resources/corda412vs411.png" figcaption="Corda 4.12 vs Corda 4.11">}} ## Upgrade scenarios diff --git a/content/en/platform/corda/4.12/community/contract-irs.md b/content/en/platform/corda/4.12/community/contract-irs.md index 5c569f927a2..538e17b551b 100644 --- a/content/en/platform/corda/4.12/community/contract-irs.md +++ b/content/en/platform/corda/4.12/community/contract-irs.md @@ -48,7 +48,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="/en/images/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="/en/images/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/platform/corda/4.12/community/cordapp-advanced-concepts.md b/content/en/platform/corda/4.12/community/cordapp-advanced-concepts.md index 8ff3a019483..20fa99b6fd8 100644 --- a/content/en/platform/corda/4.12/community/cordapp-advanced-concepts.md +++ b/content/en/platform/corda/4.12/community/cordapp-advanced-concepts.md @@ -73,7 +73,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/platform/corda/4.12/community/cordapp-overview.md b/content/en/platform/corda/4.12/community/cordapp-overview.md index 8b431db1af7..0c12f80a8be 100644 --- a/content/en/platform/corda/4.12/community/cordapp-overview.md +++ b/content/en/platform/corda/4.12/community/cordapp-overview.md @@ -22,7 +22,7 @@ CorDapps (Corda Distributed Applications) are distributed applications that run CorDapp is to allow nodes to reach agreement on updates to the ledger. They achieve this goal by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="/en/images/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="/en/images/node-diagram.png" >}} ## CorDapp components diff --git a/content/en/platform/corda/4.12/community/financial-model.md b/content/en/platform/corda/4.12/community/financial-model.md index ff144315a26..110700a0a8b 100644 --- a/content/en/platform/corda/4.12/community/financial-model.md +++ b/content/en/platform/corda/4.12/community/financial-model.md @@ -93,6 +93,6 @@ countable (in cents), barrels of West Texas crude are fungible and countable (oi container), shares of the same class in a specific company are fungible and countable, and so on. The following diagram illustrates the complete Contract State hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Note there are currently two packages, a core library and a finance model specific library. Developers may re-use or extend the Finance types directly or write their own by extending the base types from the Core library. diff --git a/content/en/platform/corda/4.12/community/key-concepts-consensus.md b/content/en/platform/corda/4.12/community/key-concepts-consensus.md index b4daae83f2c..0b16c6df058 100644 --- a/content/en/platform/corda/4.12/community/key-concepts-consensus.md +++ b/content/en/platform/corda/4.12/community/key-concepts-consensus.md @@ -49,7 +49,7 @@ transferring a treasury bond, the bond transfer is only valid if: Walking the chain for this transaction would look like this: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a node may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer. The @@ -68,7 +68,7 @@ proposals: Both transactions will achieve validity consensus, yet Alice has managed to “double-spend” her USD to get double the amount of GBP and EUR: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/platform/corda/4.12/community/key-concepts-contracts.md b/content/en/platform/corda/4.12/community/key-concepts-contracts.md index 84488b08e1a..10664b649fc 100644 --- a/content/en/platform/corda/4.12/community/key-concepts-contracts.md +++ b/content/en/platform/corda/4.12/community/key-concepts-contracts.md @@ -55,7 +55,7 @@ transaction gathers all the required signatures, it can't be executed unless it Each transaction [state]({{< relref "key-concepts-states.md" >}}) specifies a *contract type*. The contract specified takes the transaction as input, and determines if the transaction is valid based on the contract's internal rules. The contract must evaluate every input state and every output state. -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code can: * Check the number of inputs, outputs, commands, or attachments. diff --git a/content/en/platform/corda/4.12/community/key-concepts-ecosystem.md b/content/en/platform/corda/4.12/community/key-concepts-ecosystem.md index de1f99ca4dc..6d43ce4c852 100644 --- a/content/en/platform/corda/4.12/community/key-concepts-ecosystem.md +++ b/content/en/platform/corda/4.12/community/key-concepts-ecosystem.md @@ -32,7 +32,7 @@ title: Networks, identity, and discovery ## What is a network? On Corda, people and business interact by communicating over a peer-to-peer network of [Corda nodes]({{< relref "key-concepts-node.md" >}}). Each node represents a legal entity running Corda and one or more Corda distributed applications, known as [CorDapps]({{< relref "cordapp-overview.md" >}}). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} Corda is different from other distributed ledgers because all communication between nodes is point-to-point, and only shared on a need-to-know basis. It is also encrypted using transport-layer security. There are *no global broadcasts* to all parties on a network, but all of the nodes in a network can send messages directly to other nodes. If the recipient is offline, the message waits in an outbound queue until they are online again—just like an email. ## Join a network diff --git a/content/en/platform/corda/4.12/community/key-concepts-flows.md b/content/en/platform/corda/4.12/community/key-concepts-flows.md index 890a2935b38..0eb0b248193 100644 --- a/content/en/platform/corda/4.12/community/key-concepts-flows.md +++ b/content/en/platform/corda/4.12/community/key-concepts-flows.md @@ -35,7 +35,7 @@ must specify what information needs to be sent, to which counterparties, and in Here is a visualisation of Alice and Bob agreeing a ledger update using this process: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -44,7 +44,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is a diagram showing the flow's steps used between Alice and Bob to perform the ledger update: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/platform/corda/4.12/community/key-concepts-ledger.md b/content/en/platform/corda/4.12/community/key-concepts-ledger.md index f3efab4237d..d6a178ba126 100644 --- a/content/en/platform/corda/4.12/community/key-concepts-ledger.md +++ b/content/en/platform/corda/4.12/community/key-concepts-ledger.md @@ -39,7 +39,7 @@ loan are Alice and Bob, then they are the only nodes that ever see or store this This diagram shows a network with five nodes (Alice, Bob, Carl, Demi, and Ed). Each numbered circle on an intersection represents a fact shared between two or more nodes: -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} In the diagram, facts 1 and 7 are known by both Alice and Bob. Alice only shares facts with Bob, Alice doesn't share any facts with Carl, Demi, or Ed. @@ -56,7 +56,7 @@ each node maintains its own vault, which contains all of its known facts. You can think of a vault as being a database or simple table. In this diagram, facts 1 and 7 appear on both Alice's vault and Bob's vault, and are therefore shared facts: -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} When multiple nodes on a network share an evolving fact, the changes to the fact update at the same time in each node's vault. This means that Alice and Bob will both see an *identical version* of shared facts 1 and 7. diff --git a/content/en/platform/corda/4.12/community/key-concepts-node.md b/content/en/platform/corda/4.12/community/key-concepts-node.md index 72bcefefb14..cd1e7fd23c3 100644 --- a/content/en/platform/corda/4.12/community/key-concepts-node.md +++ b/content/en/platform/corda/4.12/community/key-concepts-node.md @@ -35,7 +35,7 @@ title: Nodes A Corda node runs within a Java Virtual Machine (JVM) runtime environment with a [unique network identity]({{< relref "key-concepts-ecosystem.md#node-identities" >}}). JVM runtime environments provide a consistent platform on which you can run and deploy Java applications, such as Corda services and CorDapps. Here is a visualization of the node’s internal architecture: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: diff --git a/content/en/platform/corda/4.12/community/key-concepts-states.md b/content/en/platform/corda/4.12/community/key-concepts-states.md index d73a46fd236..c8cbcb11f26 100644 --- a/content/en/platform/corda/4.12/community/key-concepts-states.md +++ b/content/en/platform/corda/4.12/community/key-concepts-states.md @@ -35,7 +35,7 @@ You can use states to represent any type of data, and any kind of fact. For exam This state represents an IOU—an agreement that Alice owes Bob £10: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} In addition to information about the fact, the state contains a reference to the **[contract]({{< relref "key-concepts-contracts.md" >}})**. Contracts govern the evolution of states. @@ -47,14 +47,14 @@ When a fact changes, one of the state's participants creates a new state and mar For example, if Alice pays Bob £5, the state sequence would be: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a **vault**. This is the node's database used to store current and historic states where the node is a participant. For example: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} From each node's point of view, the ledger is the current (non-historic) states where that node is a participant. diff --git a/content/en/platform/corda/4.12/community/key-concepts-tearoffs.md b/content/en/platform/corda/4.12/community/key-concepts-tearoffs.md index 01034c52e79..6f93fc1dec0 100644 --- a/content/en/platform/corda/4.12/community/key-concepts-tearoffs.md +++ b/content/en/platform/corda/4.12/community/key-concepts-tearoffs.md @@ -39,7 +39,7 @@ Merkle trees split transactions into "leaves". Each leaf contains either an input, an output, a command, or an attachment. The final nested tree structure also contains the other fields of the transaction, such as the time window, the notary, and the required signers. The only component type that requires two trees instead of one is the command, which is split into command data and required signers for visibility purposes. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} Corda uses one nested Merkle tree per component type. A component sub-tree is generated for each component type (for example, inputs, outputs, or attachments). The roots of these sub-trees @@ -65,7 +65,7 @@ obtained belongs to that particular transaction. In this example, assume that only the first command should be visible to the oracle. You must provide guarantees that all the commands the oracle needs to sign are visible to the oracle entity, but no other data. The transaction would be represented in the Merkle tree structure like this: -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} The blue nodes and `H(c2)` are provided to the oracle service, while the black ones are omitted. The oracle needs `H(c2)` so it can compute `H(commandData)` without being to able to see the second command. At the same time, this ensures that `CommandData1` is part of the transaction. All signers are visible as @@ -79,4 +79,4 @@ To send the same transaction to a non-validating notary, hide all components apart from input states, time window, and the notary information. This data is enough for the notary to know which input states to check for double-spending, if the time-window is valid, and if the transaction is being notarized by the correct notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/platform/corda/4.12/community/key-concepts-time-windows.md b/content/en/platform/corda/4.12/community/key-concepts-time-windows.md index a2ecd3e7d6c..9297175271d 100644 --- a/content/en/platform/corda/4.12/community/key-concepts-time-windows.md +++ b/content/en/platform/corda/4.12/community/key-concepts-time-windows.md @@ -46,7 +46,7 @@ trade, or requesting human sign-off. Times in transactions are specified as time *windows*, not absolute times. Time windows can be open-ended, and specify only “before” **or** “after”, or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} When both a before and an after time are included the transaction occurred at some point within that time window. diff --git a/content/en/platform/corda/4.12/community/key-concepts-transactions.md b/content/en/platform/corda/4.12/community/key-concepts-transactions.md index 0d96fa61fe7..655141bcdc4 100644 --- a/content/en/platform/corda/4.12/community/key-concepts-transactions.md +++ b/content/en/platform/corda/4.12/community/key-concepts-transactions.md @@ -37,7 +37,7 @@ Every [state]({{< relref "key-concepts-states.md" >}}) is *immutable*—it can't Here is an example of a transaction with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type. Transactions can: * Include different types of states representing multiple financial instruments, such as cash or bonds. @@ -65,21 +65,21 @@ Input state references consist of: You can see how this works in this example transaction: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} ## Committing transactions to the ledger Initially, a transaction is only a proposal to update the ledger. It represents the future state of the ledger desired by the transaction builders. -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To be committed to the ledger, the transaction must receive signatures from all the *required signers*. Each required signer appends their signature to the transaction to approve the proposal. -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If the transaction gathers the required signatures, it is committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions. @@ -121,7 +121,7 @@ For example, suppose Alice uses $5 cash to pay off $5 of an IOU with Bob. This transaction contains a *settlement command* which reduces the amount outstanding on the IOU, and a *payment command* which changes the ownership of $5 from Alice to Bob. It also has two supporting attachments, and is notarized by `NotaryClusterA` if the notary pool receives it within the specified time window: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -145,7 +145,7 @@ listed in the commands, you get the list of the transaction’s required signers This situation would look like this: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/platform/corda/4.12/community/key-concepts-vault.md b/content/en/platform/corda/4.12/community/key-concepts-vault.md index a9ac8f1506d..9d05cf65dc5 100644 --- a/content/en/platform/corda/4.12/community/key-concepts-vault.md +++ b/content/en/platform/corda/4.12/community/key-concepts-vault.md @@ -45,7 +45,7 @@ The vault supports the management of data in both authoritative **on-ledger** fo This diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} You can see: diff --git a/content/en/platform/corda/4.12/community/network-builder.md b/content/en/platform/corda/4.12/community/network-builder.md index 3c8e92e5879..e13d4c614c1 100644 --- a/content/en/platform/corda/4.12/community/network-builder.md +++ b/content/en/platform/corda/4.12/community/network-builder.md @@ -21,7 +21,7 @@ title: Corda Network Builder The Corda Network Builder is a tool for building Corda networks for testing purposes. It leverages Docker and containers to abstract the complexity of managing a distributed network away from the user. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} The network you build will either be made up of local `Docker` nodes *or* of nodes spread across Azure containers. For each node a separate Docker image is built based on [corda/open-source:4.12.6-zulu-openjdk](https://hub.docker.com/layers/corda/open-source/4.12.6-zulu-openjdk/images/sha256-a3ba9f68e9f28933063925508bdc4b475c8e363cee292300abf729b7b0a91a2f). diff --git a/content/en/platform/corda/4.12/community/node-administration.md b/content/en/platform/corda/4.12/community/node-administration.md index ad8a9d2603a..4aa2bc14d45 100644 --- a/content/en/platform/corda/4.12/community/node-administration.md +++ b/content/en/platform/corda/4.12/community/node-administration.md @@ -173,7 +173,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ## Memory usage and tuning diff --git a/content/en/platform/corda/4.12/community/node-database-tables.md b/content/en/platform/corda/4.12/community/node-database-tables.md index 46e9e751f35..aba0ec37e34 100644 --- a/content/en/platform/corda/4.12/community/node-database-tables.md +++ b/content/en/platform/corda/4.12/community/node-database-tables.md @@ -49,7 +49,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more here: [The network map]({{< relref "network-map.md" >}}) -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -178,7 +178,7 @@ Read more in [the ledger]({{< relref "key-concepts-ledger.md" >}}) Read more in [Working with attachments]({{< relref "../enterprise/get-started/tutorials/supplementary-tutorials/tutorial-attachments.md" >}}) and [Node services]({{< relref "node-services.md" >}}) -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -470,7 +470,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -499,7 +499,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/platform/corda/4.12/community/permissioning.md b/content/en/platform/corda/4.12/community/permissioning.md index 0c74e0115c7..46f12af17f2 100644 --- a/content/en/platform/corda/4.12/community/permissioning.md +++ b/content/en/platform/corda/4.12/community/permissioning.md @@ -52,7 +52,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="/en/images/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/platform/corda/4.12/community/upgrading-cordapps.md b/content/en/platform/corda/4.12/community/upgrading-cordapps.md index 09cfd019930..6f3402f65c4 100644 --- a/content/en/platform/corda/4.12/community/upgrading-cordapps.md +++ b/content/en/platform/corda/4.12/community/upgrading-cordapps.md @@ -74,7 +74,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="/en/images/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="/en/images/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/platform/corda/4.12/enterprise/api-core-types.md b/content/en/platform/corda/4.12/enterprise/api-core-types.md index 8ea2c181166..16f225af339 100644 --- a/content/en/platform/corda/4.12/enterprise/api-core-types.md +++ b/content/en/platform/corda/4.12/enterprise/api-core-types.md @@ -68,11 +68,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="./resources/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="./resources/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="./resources/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="./resources/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/platform/corda/4.12/enterprise/apps/bankinabox/user-interface/how-to.md b/content/en/platform/corda/4.12/enterprise/apps/bankinabox/user-interface/how-to.md index 0be5c4a0537..03226ac67b1 100644 --- a/content/en/platform/corda/4.12/enterprise/apps/bankinabox/user-interface/how-to.md +++ b/content/en/platform/corda/4.12/enterprise/apps/bankinabox/user-interface/how-to.md @@ -70,7 +70,7 @@ Follow these steps to create a new customer profile. When the customer profile is created, they will not have any accounts - you will have to create them. Learn how under [Creating accounts](#create-a-current-account). {{< /note >}} -{{< figure alt="Create customer profile" width=80% zoom="/en/gifs/create-customer-biab-1.0.gif" >}} +{{< figure alt="Create customer profile" width=80% src="/en/gifs/create-customer-biab-1.0.gif" >}} ### Create a Current account @@ -94,7 +94,7 @@ When the customer profile is created, they will not have any accounts - you will 7. When an account is created, it is in **PENDING** status. This must be changed to **ACTIVE** for a customer to be able to interact with and use the account. See [Change an account status](#change-an-account-status) for more information. -{{< figure alt="Create account" width=80% zoom="/en/gifs/create-current-account-biab-1.0.gif" >}} +{{< figure alt="Create account" width=80% src="/en/gifs/create-current-account-biab-1.0.gif" >}} ### Create a Savings account @@ -140,7 +140,7 @@ An account has three statuses: **PENDING**, **ACTIVE**, and **SUSPENDED**. When If the account needs to be suspended, follow the same steps but select **SUSPENDED**. -{{< figure alt="Set account status" width=80% zoom="/en/gifs/set-account-status-biab-1.0.gif" >}} +{{< figure alt="Set account status" width=80% src="/en/gifs/set-account-status-biab-1.0.gif" >}} ### Assign or revoke a user role @@ -163,7 +163,7 @@ To assign a user role, follow these steps: 5. Click **Revoke**. A message will appear indicating that the user role was assigned successfully. -{{< figure alt="Assign role" width=80% zoom="/en/gifs/assign-a-role-biab-1.0.gif" >}} +{{< figure alt="Assign role" width=80% src="/en/gifs/assign-a-role-biab-1.0.gif" >}} #### Revoke a user role @@ -179,7 +179,7 @@ To revoke a user role, follow these steps: 5. Click **Save**. A message will appear indicating that the user role was revoked successfully. -{{< figure alt="Revoke role" width=80% zoom="/en/gifs/revoke-role-biab-1.0.gif" >}} +{{< figure alt="Revoke role" width=80% src="/en/gifs/revoke-role-biab-1.0.gif" >}} ### Issue a loan @@ -195,7 +195,7 @@ Once the account has been set to **ACTIVE**, you will have the ability to issue A loan account is created when a loan has been issued successfully. -{{< figure alt="Issue loan" width=80% zoom="/en/gifs/issue-loan-biab-1.0.gif" >}} +{{< figure alt="Issue loan" width=80% src="/en/gifs/issue-loan-biab-1.0.gif" >}} ### Approve overdrafts @@ -215,7 +215,7 @@ To approve an overdraft, follow these steps. Overdrafts can be approved whether the account is **PENDING**, **ACTIVE**, or **SUSPENDED**. {{< /note >}} -{{< figure alt="Approve overdraft" width=80% zoom="/en/gifs/approve-overdraft-biab-1.0.gif" >}} +{{< figure alt="Approve overdraft" width=80% src="/en/gifs/approve-overdraft-biab-1.0.gif" >}} ### Deposit money to an account @@ -230,7 +230,7 @@ Follow these steps to deposit money to a customer account. 4. Click **Save**. You will receive a message indicating that the deposit was successful. -{{< figure alt="Deposit" width=80% zoom="/en/gifs/deposit-biab-1.0.gif" >}} +{{< figure alt="Deposit" width=80% src="/en/gifs/deposit-biab-1.0.gif" >}} ### Register as a user on Bank in a Box @@ -251,7 +251,7 @@ You must be registered as a **Customer** or **Admin** on Bank in a Box to perfor 5. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update customer profile @@ -284,7 +284,7 @@ An **Admin user** can set an account's **Withdrawal daily limit** or **Transfer 2. Click **Save** when you have entered the desired limits. A message will appear indicating that the limits have been saved successfully. -{{< figure alt="Set withdrawal and transfer limits - admin" width=80% zoom="/en/gifs/set-limits-admin-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - admin" width=80% src="/en/gifs/set-limits-admin-biab-1.0.gif" >}} ## Customer tasks @@ -309,12 +309,12 @@ Follow these steps to create a new intrabank payment. 6. Click **Save**. You will receive a notification indicating that the payment was created successfully. You will also receive notifications indicating any changes in your account balances. -{{< figure alt="Create intrabank payment" width=80% zoom="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} +{{< figure alt="Create intrabank payment" width=80% src="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} After making a payment, you can view the details of this transaction on the Transactions screen. -{{< figure alt="View transaction" width="800" width=80% zoom="/en/gifs/view-transaction-biab-1.0.gif" >}} +{{< figure alt="View transaction" width="800" width=80% src="/en/gifs/view-transaction-biab-1.0.gif" >}} ### Create a recurring payment @@ -338,7 +338,7 @@ Follow these steps to create a recurring payment: 3. You will be taken back to the **Recurring payments screen** where you will receive a message indicating that the recurring payment was created successfully. -{{< figure alt="Recurring payment" width=80% zoom="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} +{{< figure alt="Recurring payment" width=80% src="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} {{< note >}} This payment will not appear on the **Recurring payments screen** until the first iteration has occurred. @@ -367,7 +367,7 @@ You must be registered as a Customer or Admin on Bank in a Box to perform tasks. 7. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update a customer profile @@ -406,4 +406,4 @@ To set these limits as a **Customer**, follow these steps. 4. Click **Save**. You will be taken back to the Account page where you will receive a message indicating that the limits have been updated successfully. -{{< figure alt="Set withdrawal and transfer limits - customer" width=80% zoom="/en/gifs/set-limits-customer-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - customer" width=80% src="/en/gifs/set-limits-customer-biab-1.0.gif" >}} diff --git a/content/en/platform/corda/4.12/enterprise/contract-irs.md b/content/en/platform/corda/4.12/enterprise/contract-irs.md index 72563f5844c..c809bc286ea 100644 --- a/content/en/platform/corda/4.12/enterprise/contract-irs.md +++ b/content/en/platform/corda/4.12/enterprise/contract-irs.md @@ -45,7 +45,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="./resources/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="./resources/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/platform/corda/4.12/enterprise/cordapp-advanced-concepts.md b/content/en/platform/corda/4.12/enterprise/cordapp-advanced-concepts.md index 882e6e8e743..9ea71d2c2b6 100644 --- a/content/en/platform/corda/4.12/enterprise/cordapp-advanced-concepts.md +++ b/content/en/platform/corda/4.12/enterprise/cordapp-advanced-concepts.md @@ -71,7 +71,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="./resources/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="./resources/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/platform/corda/4.12/enterprise/cordapps/api-flows.md b/content/en/platform/corda/4.12/enterprise/cordapps/api-flows.md index 5fe702e2679..fef119ccfb4 100644 --- a/content/en/platform/corda/4.12/enterprise/cordapps/api-flows.md +++ b/content/en/platform/corda/4.12/enterprise/cordapps/api-flows.md @@ -91,7 +91,7 @@ The `initiator`: You can visualize the work performed by initiator like this: -{{< figure alt="flow overview" width=80% zoom="../resources/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="../resources/flow-overview.png" >}} ## Responder flow class example diff --git a/content/en/platform/corda/4.12/enterprise/cordapps/api-states.md b/content/en/platform/corda/4.12/enterprise/cordapps/api-states.md index 3fc9f7c5468..d688eac1e5d 100644 --- a/content/en/platform/corda/4.12/enterprise/cordapps/api-states.md +++ b/content/en/platform/corda/4.12/enterprise/cordapps/api-states.md @@ -62,7 +62,7 @@ states evolve in a straight line by superseding themselves. You can visualize the hierarchy like this: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/platform/corda/4.12/enterprise/cordapps/cordapp-overview.md b/content/en/platform/corda/4.12/enterprise/cordapps/cordapp-overview.md index a3c48cf7013..430bc12cd0a 100644 --- a/content/en/platform/corda/4.12/enterprise/cordapps/cordapp-overview.md +++ b/content/en/platform/corda/4.12/enterprise/cordapps/cordapp-overview.md @@ -31,7 +31,7 @@ CorDapps are: A Corda Distributed Application (CorDapp) solves a specific problem using the Corda framework. CorDapps are stored on Corda nodes and executed on the Corda network. This *distributes* the app, allowing it to run on multiple systems simultaneously—unlike traditional apps, which utilize one dedicated system to achieve an assigned task. CorDapps let nodes communicate with each other to reach agreement on updates to the ledger by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="../resources/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="../resources/node-diagram.png" >}} ## Glossary diff --git a/content/en/platform/corda/4.12/enterprise/cordapps/upgrading-cordapps.md b/content/en/platform/corda/4.12/enterprise/cordapps/upgrading-cordapps.md index f0a4f393e5d..8f5c6b5c865 100644 --- a/content/en/platform/corda/4.12/enterprise/cordapps/upgrading-cordapps.md +++ b/content/en/platform/corda/4.12/enterprise/cordapps/upgrading-cordapps.md @@ -68,7 +68,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="../resources/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="../resources/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/platform/corda/4.12/enterprise/financial-model.md b/content/en/platform/corda/4.12/enterprise/financial-model.md index eb021af03e3..d7cf1f2a262 100644 --- a/content/en/platform/corda/4.12/enterprise/financial-model.md +++ b/content/en/platform/corda/4.12/enterprise/financial-model.md @@ -92,6 +92,6 @@ countable (in cents), barrels of oil are fungible and countable (oil from two sm container), shares of the same class in a specific company are fungible and countable, and so on. This diagram illustrates the complete contract state hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Corda provides two packages: a core library and a finance model-specific library. You can re-use or extend the finance types directly, or write your own by extending the base types from the core library. diff --git a/content/en/platform/corda/4.12/enterprise/health-survey.md b/content/en/platform/corda/4.12/enterprise/health-survey.md index 3ffdcfd4561..35a0a8c41a4 100644 --- a/content/en/platform/corda/4.12/enterprise/health-survey.md +++ b/content/en/platform/corda/4.12/enterprise/health-survey.md @@ -116,7 +116,7 @@ The Corda Health Survey currently does not support testing RPC communication if The tool generates the archive of the collected files in the same directory it is ran in. The names are in the format: `report-date-time.zip` -{{< figure alt="health survey photo" width=80% zoom="resources/health-survey-photo.png" >}} +{{< figure alt="health survey photo" width=80% src="resources/health-survey-photo.png" >}} ## Deployment health check diff --git a/content/en/platform/corda/4.12/enterprise/key-concepts-consensus.md b/content/en/platform/corda/4.12/enterprise/key-concepts-consensus.md index ba7710534b1..befb0464744 100644 --- a/content/en/platform/corda/4.12/enterprise/key-concepts-consensus.md +++ b/content/en/platform/corda/4.12/enterprise/key-concepts-consensus.md @@ -48,7 +48,7 @@ transferring a treasury bond, the bond transfer is only valid if: Walking the chain for this transaction would look like this: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a node may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer. The @@ -67,7 +67,7 @@ proposals: Both transactions will achieve validity consensus, yet Alice has managed to “double-spend” her USD to get double the amount of GBP and EUR: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/platform/corda/4.12/enterprise/key-concepts-contracts.md b/content/en/platform/corda/4.12/enterprise/key-concepts-contracts.md index 54ee7b9482e..71de8661397 100644 --- a/content/en/platform/corda/4.12/enterprise/key-concepts-contracts.md +++ b/content/en/platform/corda/4.12/enterprise/key-concepts-contracts.md @@ -55,7 +55,7 @@ transaction gathers all the required signatures, it can't be executed unless it Each transaction [state]({{< relref "key-concepts-states.md" >}}) specifies a *contract type*. The contract specified takes the transaction as input, and determines if the transaction is valid based on the contract's internal rules. The contract must evaluate every input state and every output state. -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code can: * Check the number of inputs, outputs, commands, or attachments. diff --git a/content/en/platform/corda/4.12/enterprise/key-concepts-ecosystem.md b/content/en/platform/corda/4.12/enterprise/key-concepts-ecosystem.md index e3437aa1171..dca27f8d871 100644 --- a/content/en/platform/corda/4.12/enterprise/key-concepts-ecosystem.md +++ b/content/en/platform/corda/4.12/enterprise/key-concepts-ecosystem.md @@ -32,7 +32,7 @@ title: Networks, identity, and discovery ## What is a network? On Corda, people and business interact by communicating over a peer-to-peer network of [Corda nodes]({{< relref "key-concepts-node.md" >}}). Each node represents a legal entity running Corda and one or more Corda distributed applications, known as [CorDapps]({{< relref "cordapps/cordapp-overview.md" >}}). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} Corda is different from other distributed ledgers because all communication between nodes is point-to-point, and only shared on a need-to-know basis. It is also encrypted using transport-layer security. There are *no global broadcasts* to all parties on a network, but all of the nodes in a network can send messages directly to other nodes. If the recipient is offline, the message waits in an outbound queue until they are online again—just like an email. ## Join a network diff --git a/content/en/platform/corda/4.12/enterprise/key-concepts-flows.md b/content/en/platform/corda/4.12/enterprise/key-concepts-flows.md index 7ac59e14479..4a821f27ab6 100644 --- a/content/en/platform/corda/4.12/enterprise/key-concepts-flows.md +++ b/content/en/platform/corda/4.12/enterprise/key-concepts-flows.md @@ -35,7 +35,7 @@ must specify what information needs to be sent, to which counterparties, and in Here is a visualisation of Alice and Bob agreeing a ledger update using this process: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -44,7 +44,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is a diagram showing the flow's steps used between Alice and Bob to perform the ledger update: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/platform/corda/4.12/enterprise/key-concepts-ledger.md b/content/en/platform/corda/4.12/enterprise/key-concepts-ledger.md index 848a33ac31a..1a371789387 100644 --- a/content/en/platform/corda/4.12/enterprise/key-concepts-ledger.md +++ b/content/en/platform/corda/4.12/enterprise/key-concepts-ledger.md @@ -39,7 +39,7 @@ loan are Alice and Bob, then they are the only nodes that ever see or store this This diagram shows a network with five nodes (Alice, Bob, Carl, Demi, and Ed). Each numbered circle on an intersection represents a fact shared between two or more nodes: -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} In the diagram, facts 1 and 7 are known by both Alice and Bob. Alice only shares facts with Bob, Alice doesn't share any facts with Carl, Demi, or Ed. @@ -56,7 +56,7 @@ each node maintains its own vault, which contains all of its known facts. You can think of a vault as being a database or simple table. In this diagram, facts 1 and 7 appear on both Alice's vault and Bob's vault, and are therefore shared facts: -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} When multiple nodes on a network share an evolving fact, the changes to the fact update at the same time in each node's vault. This means that Alice and Bob will both see an *identical version* of shared facts 1 and 7. diff --git a/content/en/platform/corda/4.12/enterprise/key-concepts-node.md b/content/en/platform/corda/4.12/enterprise/key-concepts-node.md index 9964f777966..54a506be05c 100644 --- a/content/en/platform/corda/4.12/enterprise/key-concepts-node.md +++ b/content/en/platform/corda/4.12/enterprise/key-concepts-node.md @@ -35,7 +35,7 @@ title: Nodes A Corda node runs within a Java Virtual Machine (JVM) runtime environment with a [unique network identity]({{< relref "key-concepts-ecosystem.md#node-identities" >}}). JVM runtime environments provide a consistent platform on which you can run and deploy Java applications, such as Corda services and CorDapps. Here is a visualization of the node’s internal architecture: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: diff --git a/content/en/platform/corda/4.12/enterprise/key-concepts-states.md b/content/en/platform/corda/4.12/enterprise/key-concepts-states.md index 3ca30bb83d1..d647a31415f 100644 --- a/content/en/platform/corda/4.12/enterprise/key-concepts-states.md +++ b/content/en/platform/corda/4.12/enterprise/key-concepts-states.md @@ -35,7 +35,7 @@ You can use states to represent any type of data, and any kind of fact. For exam This state represents an IOU—an agreement that Alice owes Bob £10: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} In addition to information about the fact, the state contains a reference to the **[contract]({{< relref "key-concepts-contracts.md" >}})**. Contracts govern the evolution of states. @@ -47,14 +47,14 @@ When a fact changes, one of the state's participants creates a new state and mar For example, if Alice pays Bob £5, the state sequence would be: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a **vault**. This is the node's database used to store current and historic states where the node is a participant. For example: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} From each node's point of view, the ledger is the current (non-historic) states where that node is a participant. diff --git a/content/en/platform/corda/4.12/enterprise/key-concepts-tearoffs.md b/content/en/platform/corda/4.12/enterprise/key-concepts-tearoffs.md index 3e7515719c0..a76b1ea15a3 100644 --- a/content/en/platform/corda/4.12/enterprise/key-concepts-tearoffs.md +++ b/content/en/platform/corda/4.12/enterprise/key-concepts-tearoffs.md @@ -39,7 +39,7 @@ Merkle trees split transactions into "leaves". Each leaf contains either an input, an output, a command, or an attachment. The final nested tree structure also contains the other fields of the transaction, such as the time window, the notary, and the required signers. The only component type that requires two trees instead of one is the command, which is split into command data and required signers for visibility purposes. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} Corda uses one nested Merkle tree per component type. A component sub-tree is generated for each component type (for example, inputs, outputs, or attachments). The roots of these sub-trees @@ -65,7 +65,7 @@ obtained belongs to that particular transaction. In this example, assume that only the first command should be visible to the oracle. You must provide guarantees that all the commands the oracle needs to sign are visible to the oracle entity, but no other data. The transaction would be represented in the Merkle tree structure like this: -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} The blue nodes and `H(c2)` are provided to the oracle service, while the black ones are omitted. The oracle needs `H(c2)` so it can compute `H(commandData)` without being to able to see the second command. At the same time, this ensures that `CommandData1` is part of the transaction. All signers are visible as @@ -79,4 +79,4 @@ To send the same transaction to a non-validating notary, hide all components apart from input states, time window, and the notary information. This data is enough for the notary to know which input states to check for double-spending, if the time-window is valid, and if the transaction is being notarized by the correct notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/platform/corda/4.12/enterprise/key-concepts-time-windows.md b/content/en/platform/corda/4.12/enterprise/key-concepts-time-windows.md index 95dc279bcfb..f76f7fc81c5 100644 --- a/content/en/platform/corda/4.12/enterprise/key-concepts-time-windows.md +++ b/content/en/platform/corda/4.12/enterprise/key-concepts-time-windows.md @@ -46,7 +46,7 @@ trade, or requesting human sign-off. Times in transactions are specified as time *windows*, not absolute times. Time windows can be open-ended, and specify only “before” **or** “after”, or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} When both a before and an after time are included the transaction occurred at some point within that time window. diff --git a/content/en/platform/corda/4.12/enterprise/key-concepts-transactions.md b/content/en/platform/corda/4.12/enterprise/key-concepts-transactions.md index 390bc8d2250..8b3ba6bfdd1 100644 --- a/content/en/platform/corda/4.12/enterprise/key-concepts-transactions.md +++ b/content/en/platform/corda/4.12/enterprise/key-concepts-transactions.md @@ -37,7 +37,7 @@ Every [state]({{< relref "key-concepts-states.md" >}}) is *immutable*—it can't Here is an example of a transaction with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type. Transactions can: * Include different types of states representing multiple financial instruments, such as cash or bonds. @@ -65,21 +65,21 @@ Input state references consist of: You can see how this works in this example transaction: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} ## Committing transactions to the ledger Initially, a transaction is only a proposal to update the ledger. It represents the future state of the ledger desired by the transaction builders. -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To be committed to the ledger, the transaction must receive signatures from all the *required signers*. Each required signer appends their signature to the transaction to approve the proposal. -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If the transaction gathers the required signatures, it is committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions. @@ -121,7 +121,7 @@ For example, suppose Alice uses $5 cash to pay off $5 of an IOU with Bob. This transaction contains a *settlement command* which reduces the amount outstanding on the IOU, and a *payment command* which changes the ownership of $5 from Alice to Bob. It also has two supporting attachments, and is notarized by `NotaryClusterA` if the notary pool receives it within the specified time window: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -145,7 +145,7 @@ listed in the commands, you get the list of the transaction’s required signers This situation would look like this: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/platform/corda/4.12/enterprise/key-concepts-vault.md b/content/en/platform/corda/4.12/enterprise/key-concepts-vault.md index 47cc18d68bc..ad4a828e22d 100644 --- a/content/en/platform/corda/4.12/enterprise/key-concepts-vault.md +++ b/content/en/platform/corda/4.12/enterprise/key-concepts-vault.md @@ -46,7 +46,7 @@ The vault supports the management of data in both authoritative **on-ledger** fo This diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} You can see: diff --git a/content/en/platform/corda/4.12/enterprise/network-builder.md b/content/en/platform/corda/4.12/enterprise/network-builder.md index 906af3fc2bd..6158fb9fd55 100644 --- a/content/en/platform/corda/4.12/enterprise/network-builder.md +++ b/content/en/platform/corda/4.12/enterprise/network-builder.md @@ -21,7 +21,7 @@ title: Corda Network Builder The Corda Network Builder is a tool for building Corda networks for testing purposes. It leverages Docker and containers to abstract the complexity of managing a distributed network away from the user. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} The network you build will either be made up of local `Docker` nodes *or* of nodes spread across Azure containers. For each node a separate Docker image is built based on [corda/corda-enterprise:4.12.6-zulu-openjdk-alpine](https://hub.docker.com/layers/corda/corda-enterprise/4.12.6-zulu-openjdk-alpine/images/sha256-6f998943406c8fa9aa493aacbbab32bf1aa2e346ec4cf7cca027300caba3a119). diff --git a/content/en/platform/corda/4.12/enterprise/network/cipher-suites.md b/content/en/platform/corda/4.12/enterprise/network/cipher-suites.md index b939afa5fa3..c3e7e89e28a 100644 --- a/content/en/platform/corda/4.12/enterprise/network/cipher-suites.md +++ b/content/en/platform/corda/4.12/enterprise/network/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates]({{< relref "permissioning.md" >}})): -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/platform/corda/4.12/enterprise/network/permissioning.md b/content/en/platform/corda/4.12/enterprise/network/permissioning.md index 9dafab48bb9..0da6dd8decd 100644 --- a/content/en/platform/corda/4.12/enterprise/network/permissioning.md +++ b/content/en/platform/corda/4.12/enterprise/network/permissioning.md @@ -42,7 +42,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/platform/corda/4.12/enterprise/node/component-topology.md b/content/en/platform/corda/4.12/enterprise/node/component-topology.md index 62146bd2e4f..94b0ad3424a 100644 --- a/content/en/platform/corda/4.12/enterprise/node/component-topology.md +++ b/content/en/platform/corda/4.12/enterprise/node/component-topology.md @@ -33,7 +33,7 @@ The key node components and services are: * The Corda firewall -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" figcaption="Node internal architecture.">}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" figcaption="Node internal architecture.">}} ### CorDapps @@ -83,14 +83,14 @@ Nodes communicate with other nodes using asynchronous AMQP/TLS 1.2 protocols. HT Nodes communicate with client applications using RPC calls. -{{< figure alt="overview" width=80% zoom="../resources/overview.png" >}} +{{< figure alt="overview" width=80% src="../resources/overview.png" >}} ## Typical node deployments In most cases, nodes are deployed with this architecture: -{{< figure alt="nodebridgefloat nbrs" width=80% zoom="../resources/nodebridgefloat_nbrs.png" figcaption="A typical node deployment.">}} +{{< figure alt="nodebridgefloat nbrs" width=80% src="../resources/nodebridgefloat_nbrs.png" figcaption="A typical node deployment.">}} Most production deployments of Corda Enterprise include nodes, vaults, and firewalls. diff --git a/content/en/platform/corda/4.12/enterprise/node/corda-firewall-component.md b/content/en/platform/corda/4.12/enterprise/node/corda-firewall-component.md index d69a0d6b30d..e05193f9fdc 100644 --- a/content/en/platform/corda/4.12/enterprise/node/corda-firewall-component.md +++ b/content/en/platform/corda/4.12/enterprise/node/corda-firewall-component.md @@ -140,7 +140,7 @@ Artemis with the node as TLS endpoint and to have the outgoing packets use the i Typically this should only be used for easy development, or for organisations evaluating on Open Source Corda, where this is the only available option: -{{< figure alt="node embedded bridge" width=80% zoom="/en/images/node_embedded_bridge.png" >}} +{{< figure alt="node embedded bridge" width=80% src="/en/images/node_embedded_bridge.png" >}} ### Node + Combined Bridge/Float (no DMZ) @@ -170,7 +170,7 @@ Then configure an all-in-one bridge to point at this node’s `messagingServerAd {{< /note >}} -{{< figure alt="simple bridge" width=80% zoom="/en/images/simple_bridge.png" >}} +{{< figure alt="simple bridge" width=80% src="/en/images/simple_bridge.png" >}} #### node.conf @@ -238,7 +238,7 @@ key, the tunnel link should use a private set of link specific keys and certific dynamically with the official TLS key when activated via the tunnel and this key will never be stored in the DMZ: {{< /note >}} -{{< figure alt="node bridge float" width=80% zoom="/en/images/node_bridge_float.png" >}} +{{< figure alt="node bridge float" width=80% src="/en/images/node_bridge_float.png" >}} #### node.conf @@ -326,7 +326,7 @@ Some organisations require dynamic outgoing connections to operate via a SOCKS p by adding extra information to the `outboundConfig` section of the bridge process. A simplified example deployment is shown here to highlight the option: -{{< figure alt="socks proxy" width=80% zoom="/en/images/socks_proxy.png" >}} +{{< figure alt="socks proxy" width=80% src="/en/images/socks_proxy.png" >}} #### node.conf @@ -426,7 +426,7 @@ Highlighted in the diagram is the addition of the `haConfig` section to point at addresses in the `alternateArtemisAddresses` to allow node failover and in the `floatAddresses` to point at a pool of DMZ float processes. -{{< figure alt="ha nodes" width=80% zoom="/en/images/ha_nodes.png" >}} +{{< figure alt="ha nodes" width=80% src="/en/images/ha_nodes.png" >}} #### node.conf @@ -563,7 +563,7 @@ It is possible to allow two or more Corda nodes (HA and/or non-HA) handle outgoi an external Artemis messaging broker which can be easily configured using the ha-tool. For more information, please see HA Utilities. While this example is the simplest deployment possible with a shared bridge, any other configuration previously presented can be created. -{{< figure alt="multiple nodes no ha" width=80% zoom="/en/images/multiple_nodes_no_ha.png" >}} +{{< figure alt="multiple nodes no ha" width=80% src="/en/images/multiple_nodes_no_ha.png" >}} #### bank-a-node.conf diff --git a/content/en/platform/corda/4.12/enterprise/node/corda-firewall-configuration-file.md b/content/en/platform/corda/4.12/enterprise/node/corda-firewall-configuration-file.md index 41d3ea8eebb..afd45b90e34 100644 --- a/content/en/platform/corda/4.12/enterprise/node/corda-firewall-configuration-file.md +++ b/content/en/platform/corda/4.12/enterprise/node/corda-firewall-configuration-file.md @@ -132,14 +132,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -152,7 +152,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/platform/corda/4.12/enterprise/node/deploy/env-prod-test.md b/content/en/platform/corda/4.12/enterprise/node/deploy/env-prod-test.md index 0b7aa21c354..857050bf32e 100644 --- a/content/en/platform/corda/4.12/enterprise/node/deploy/env-prod-test.md +++ b/content/en/platform/corda/4.12/enterprise/node/deploy/env-prod-test.md @@ -33,12 +33,12 @@ There are alternative approaches to how these components are deployed. For the p When deploying Corda Enterprise in a testing environment the Node, Bridge, and Float components should be deployed in a non-HA configuration as shown in the following diagram. -{{< figure alt="nonha" width=80% zoom="../../resources/nonha.png" >}} +{{< figure alt="nonha" width=80% src="../../resources/nonha.png" >}} When deploying Corda Enterprise in a production environment, the Node, Bridge, and Float components should be deployed in a high-availability configuration. -{{< figure alt="ha" width=80% zoom="../../resources/ha.png" >}} +{{< figure alt="ha" width=80% src="../../resources/ha.png" >}} ### Deployment details @@ -206,7 +206,7 @@ This is a sample `node.conf` which details a configuration connecting to a Corda In a bank environment there will typically be several layers of security protecting the firms data. -{{< figure alt="cordarch" width=80% zoom="../../resources/cordarch.png" >}} +{{< figure alt="cordarch" width=80% src="../../resources/cordarch.png" >}} *Network Authentication* @@ -220,7 +220,7 @@ In a bank environment there will typically be several layers of security protect * Corda PKI Authentication issued by Corda Network can link the Node and Bridge i.e. the red keys indicated below truststore and sslkeystore * Local PKI Authentication issued by separate CA will link the Bridge and Float i.e the purple keys indicated below trust and Bridge. -{{< figure alt="firewallpki" width=80% zoom="../../resources/firewallpki.png" >}} +{{< figure alt="firewallpki" width=80% src="../../resources/firewallpki.png" >}} The key thing is to look at this from the perspective of a bank implementing these Corda and Local PKI keys. @@ -375,7 +375,7 @@ Administrative logins with the Corda node happen via ssh whose port is configure The following image may be helpful in ensuring alignment between the Node, Bridge and Float configuration files. -{{< figure alt="CordaFirewallConfigAlign" width=80% zoom="../../resources/CordaFirewallConfigAlign.png" >}} +{{< figure alt="CordaFirewallConfigAlign" width=80% src="../../resources/CordaFirewallConfigAlign.png" >}} {{< note >}} **p2pAddress** reflects the **publicly accessible address**, which may or may not be the Float inboundConfig.listeningAddress. If there is an internet firewall configured in front of the Float then ask the Network Administrator for the public address that routes to the Float’s **listeningAddress**, and use that public address for your **p2pAddress**. diff --git a/content/en/platform/corda/4.12/enterprise/node/deploy/hot-cold-deployment.md b/content/en/platform/corda/4.12/enterprise/node/deploy/hot-cold-deployment.md index 5eaafff35cd..21edc1a018c 100644 --- a/content/en/platform/corda/4.12/enterprise/node/deploy/hot-cold-deployment.md +++ b/content/en/platform/corda/4.12/enterprise/node/deploy/hot-cold-deployment.md @@ -36,7 +36,7 @@ resources for both **Microsoft Azure** and **Amazon Web Services**. The image be result from following the guide. There will be two Corda Enterprise nodes, one active and the other inactive. Each node will represent the same legal identity inside the Corda network. Both will share a database and a network file system. -{{< figure alt="hot cold" width=80% zoom="../../resources/hot-cold.png" >}} +{{< figure alt="hot cold" width=80% src="../../resources/hot-cold.png" >}} ## Configuring the load balancer diff --git a/content/en/platform/corda/4.12/enterprise/node/operating/node-administration.md b/content/en/platform/corda/4.12/enterprise/node/operating/node-administration.md index db56166670e..2c1a555db38 100644 --- a/content/en/platform/corda/4.12/enterprise/node/operating/node-administration.md +++ b/content/en/platform/corda/4.12/enterprise/node/operating/node-administration.md @@ -245,7 +245,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ### Monitoring via Graphite diff --git a/content/en/platform/corda/4.12/enterprise/node/operating/node-database-tables.md b/content/en/platform/corda/4.12/enterprise/node/operating/node-database-tables.md index 12fbd9d00dd..60367542c53 100644 --- a/content/en/platform/corda/4.12/enterprise/node/operating/node-database-tables.md +++ b/content/en/platform/corda/4.12/enterprise/node/operating/node-database-tables.md @@ -42,7 +42,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more in [Network map]({{< relref "../../network/network-map.md" >}}). -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -170,7 +170,7 @@ Read more in [Ledger]({{< relref "../../key-concepts-ledger.md" >}}). ### Attachments Read more in [Working with attachments]({{< relref "../../get-started/tutorials/supplementary-tutorials/tutorial-attachments.md" >}}) and [Node services]({{< relref "../../node-services.md" >}}). -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -518,7 +518,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -547,7 +547,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/platform/corda/4.12/enterprise/node/pki-guide.md b/content/en/platform/corda/4.12/enterprise/node/pki-guide.md index ed8a2159883..77b0cd9e787 100644 --- a/content/en/platform/corda/4.12/enterprise/node/pki-guide.md +++ b/content/en/platform/corda/4.12/enterprise/node/pki-guide.md @@ -54,7 +54,7 @@ as they root to the same certificate. Other than that, Corda nodes stay agnostic to the certificate hierarchy (in particular the depth of the certificate hierarchy tree). -{{< figure alt="hierarchy agnostic" width=80% zoom="../resources/hierarchy-agnostic.png" >}} +{{< figure alt="hierarchy agnostic" width=80% src="../resources/hierarchy-agnostic.png" >}} At the time of writing this document, a Corda network assumes the certificate hierarchy that can be found in the [Certificate hierarchy guide]({{< relref "../network/permissioning.md#certificate-hierarchy" >}}). @@ -69,7 +69,7 @@ The network operator is responsible for certificate issuance and maintenance for at the Identity Manager and Network Map certificates. The rest of the certificate chain (i.e. every certificate below the Identity Manager certificate) falls into node operator responsibility. -{{< figure alt="tls hierarchy" width=80% zoom="../resources/tls-hierarchy.png" >}} +{{< figure alt="tls hierarchy" width=80% src="../resources/tls-hierarchy.png" >}} The certificate revocation list verification applies to the entire chain. This means that every certificate in the chain is going to be validated against the corresponding certificate revocation list during the SSL handshake. Consequently, this means that a node operator is expected to provide and maintain the certificate revocation list for the Node CA. @@ -87,7 +87,7 @@ During the certificate revocation list validation process the trust store is con As an example, let us consider the following certificate hierarchy: -{{< figure alt="example hierarchy" width=80% zoom="../resources/example-hierarchy.png" >}} +{{< figure alt="example hierarchy" width=80% src="../resources/example-hierarchy.png" >}} The certificate hierarchy presented above is currently (as of the time of writing this document) used in the Corda Network. It follows practices applicable for certificate authorities providing a balance between security and simplicity of usage. In this scenario, a network operator wants to create a CA hierarchy where the self-signed Root CA issues a certificate for the Subordinate CA which in turn issues diff --git a/content/en/platform/corda/4.12/enterprise/notary-healthcheck.md b/content/en/platform/corda/4.12/enterprise/notary-healthcheck.md index cb7ddb1102e..27317a43db0 100644 --- a/content/en/platform/corda/4.12/enterprise/notary-healthcheck.md +++ b/content/en/platform/corda/4.12/enterprise/notary-healthcheck.md @@ -171,4 +171,4 @@ monitor notary health via a dashboard or hook up an alerter. As an example, this view on a failing notary check. Note the metrics for *success*, *fail*, *inflight*, and *maxinflightTime* for the notary service and the cluster members on the left hand side. -{{< figure alt="hawtio healthcheck" width=80% zoom="./resources/hawtio-healthcheck.png" >}} +{{< figure alt="hawtio healthcheck" width=80% src="./resources/hawtio-healthcheck.png" >}} diff --git a/content/en/platform/corda/4.12/enterprise/notary/backup-restore.md b/content/en/platform/corda/4.12/enterprise/notary/backup-restore.md index 6e0e15ad40d..7c5e113f488 100644 --- a/content/en/platform/corda/4.12/enterprise/notary/backup-restore.md +++ b/content/en/platform/corda/4.12/enterprise/notary/backup-restore.md @@ -29,7 +29,7 @@ Additionally, it is critical to have a backup of the Notary Service identity pri The following diagram highlights in blue which storage components should be backed up. -{{< figure alt="storage components" width=80% zoom="../resources/storage-components.png" >}} +{{< figure alt="storage components" width=80% src="../resources/storage-components.png" >}} Note that for regular nodes it is very important to back up the Messaging Broker (Artemis) folder and the local Database, but for HA notary nodes that are purely used for notarisation purposes that is not needed. To summarise: diff --git a/content/en/platform/corda/4.12/enterprise/notary/ha-notary-service-overview.md b/content/en/platform/corda/4.12/enterprise/notary/ha-notary-service-overview.md index 46e1006700a..0c011c56dcb 100644 --- a/content/en/platform/corda/4.12/enterprise/notary/ha-notary-service-overview.md +++ b/content/en/platform/corda/4.12/enterprise/notary/ha-notary-service-overview.md @@ -60,7 +60,7 @@ database to store its node state (e.g. its identity information). We can visualise this set-up as follows, with the regular Corda nodes in green, the Corda notary worker nodes in red, and the standard node databases and notary state database replicas in blue. -{{< figure alt="ha notary overview2" width=80% zoom="../resources/ha-notary-overview2.png" >}} +{{< figure alt="ha notary overview2" width=80% src="../resources/ha-notary-overview2.png" >}} Nodes requesting notarisation from a highly-available notary will connect to the notary workers in round-robin fashion. Provided there are multiple notary workers and the notary state database is configured to be highly-available, the overall notary service @@ -73,7 +73,7 @@ In production, R3 recommends running five or more replicas in the notary state d If desired, you can choose to run each database server and its Corda notary worker on the same machine: -{{< figure alt="ha notary colocated" width=80% zoom="../resources/ha-notary-colocated.png" >}} +{{< figure alt="ha notary colocated" width=80% src="../resources/ha-notary-colocated.png" >}} ## Notary configuration diff --git a/content/en/platform/corda/4.12/enterprise/notary/hsm-support.md b/content/en/platform/corda/4.12/enterprise/notary/hsm-support.md index c0b350d1fbf..4b754c815ca 100644 --- a/content/en/platform/corda/4.12/enterprise/notary/hsm-support.md +++ b/content/en/platform/corda/4.12/enterprise/notary/hsm-support.md @@ -14,7 +14,7 @@ weight: 3 ## Overview -{{< figure alt="hsm support" width=80% zoom="../resources/hsm-support.png" >}} +{{< figure alt="hsm support" width=80% src="../resources/hsm-support.png" >}} Two notary workers and their relevant cryptographic keys used for P2P messaging and transaction signing. The red rectangles represent the Corda notary worker services. The distinct identity keys are represented by rectangles in green and yellow and the shared key of the notary service identity is drawn in blue. Their cryptographic keys are held in a single HSM. diff --git a/content/en/platform/corda/4.12/enterprise/operations/deployment/firewall-deployment.md b/content/en/platform/corda/4.12/enterprise/operations/deployment/firewall-deployment.md index 0bfbd7ed668..b85bce04c12 100644 --- a/content/en/platform/corda/4.12/enterprise/operations/deployment/firewall-deployment.md +++ b/content/en/platform/corda/4.12/enterprise/operations/deployment/firewall-deployment.md @@ -129,14 +129,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -149,7 +149,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/platform/corda/4.12/enterprise/performance-testing/introduction.md b/content/en/platform/corda/4.12/enterprise/performance-testing/introduction.md index 15a6a22a861..cbe7bf1932d 100644 --- a/content/en/platform/corda/4.12/enterprise/performance-testing/introduction.md +++ b/content/en/platform/corda/4.12/enterprise/performance-testing/introduction.md @@ -110,7 +110,7 @@ The driving app sits outside the network and connects to the JMeter servers thro measuring the throughput of a node, the test definition instructs all JMeter servers to open RPC connections to one node, thus saturating the RPC handler and driving the node as hard as possible. The test might invoke a flow that can be completed locally (for example, cash issuance) or it might require exchanging P2P messages with other nodes (for example, cash payment). -{{< figure alt="jmeter network overview" width=80% zoom="../resources/jmeter-network-overview.png" >}} +{{< figure alt="jmeter network overview" width=80% src="../resources/jmeter-network-overview.png" >}} ## Performance tests diff --git a/content/en/platform/corda/4.12/enterprise/performance-testing/jmeter-samplers.md b/content/en/platform/corda/4.12/enterprise/performance-testing/jmeter-samplers.md index c284b0086ee..53fc5d95a57 100644 --- a/content/en/platform/corda/4.12/enterprise/performance-testing/jmeter-samplers.md +++ b/content/en/platform/corda/4.12/enterprise/performance-testing/jmeter-samplers.md @@ -66,7 +66,7 @@ server, not the client machine. * `minimumNodePlatformVersion`: the minimum platform version that the JMeter client will require from the Corda nodes. It defaults to 4, which can be used to test with Corda 4.0 nodes or later. * `username`: the RPC user name of the Corda node. * `password`: the RPC password of the Corda node. -{{< figure alt="empty flow sampler" width=80% zoom="../resources/empty-flow-sampler.png" >}} +{{< figure alt="empty flow sampler" width=80% src="../resources/empty-flow-sampler.png" >}} * `CashIssueSampler`: this sampler client has the class name `com.r3.corda.jmeter.CashIssueSampler` and starts the flow `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueFlow`. This flow self-issues 1.1 billion cash tokens on the node it is running on, and stores it in the vault. In addition to the common properties described for `EmptyFlowSampler` above, this sampler client also requires: * `notaryName`: the X500 name of the notary that is acceptable to transfer cash tokens issued via this sampler. Issuing tokens does not need to be notarised, and therefore invoking this sampler does not create traffic to the notary. However, the notary is stored as part of the cash state and must be valid to do anything else with the cash state, therefore this sampler checks the notary identity against the network parameters of the node. * `CashIssueAndPaySampler`: this sampler client has the classname `com.r3.corda.jmeter.CashIssueAndPaySampler` and, depending on its parameters, it can start either of these flows - `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndPaymentFlow` or `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndpaymentNoSelection`. Either way it issues 2 million dollars in tokens and then transfers the sum to a configurable other node, thus invoking the full vault access, peer-to-peer communication and notarisation cycle. In addition to the parameters required for `CashIssueSampler`, this sampler also requires: diff --git a/content/en/platform/corda/4.12/enterprise/performance-testing/jmeter-testplans.md b/content/en/platform/corda/4.12/enterprise/performance-testing/jmeter-testplans.md index 616e6eff371..819078ebb44 100644 --- a/content/en/platform/corda/4.12/enterprise/performance-testing/jmeter-testplans.md +++ b/content/en/platform/corda/4.12/enterprise/performance-testing/jmeter-testplans.md @@ -25,12 +25,12 @@ The testplan is a hierarchy of configuration elements. The only elements used in *Variables*, *Thread Groups*, *Samplers* and *Listeners*. Rather than creating a new testplan from scratch, it might a good idea to take a copy of one of the provided example test plans and modify that. -{{< figure alt="jmeter testplan" width=80% zoom="../resources/jmeter-testplan.png" >}} +{{< figure alt="jmeter testplan" width=80% src="../resources/jmeter-testplan.png" >}} A variables element defines key/value pairs that can be used in all following following elements instead of string literals. They can be referenced by using a `$` sign and curly braces, e.g. `${varName}`. -{{< figure alt="variables" width=80% zoom="../resources/variables.png" >}} +{{< figure alt="variables" width=80% src="../resources/variables.png" >}} A thread group collects a set of actions that form one step in the test plan. All elements within a thread group diff --git a/content/en/platform/corda/4.12/enterprise/performance-testing/performance-results.md b/content/en/platform/corda/4.12/enterprise/performance-testing/performance-results.md index 43fe5289a0d..4b86ba59fd1 100644 --- a/content/en/platform/corda/4.12/enterprise/performance-testing/performance-results.md +++ b/content/en/platform/corda/4.12/enterprise/performance-testing/performance-results.md @@ -40,7 +40,7 @@ the time of Corda Enterprise Edition 4 release). This is with each node running running **Microsoft SQL Server**. Similar results were obtained against the other supported databases. -{{< figure alt="ce4 comparison chart" width=80% zoom="/en/images/ce4-comparison-chart.png" >}} +{{< figure alt="ce4 comparison chart" width=80% src="/en/images/ce4-comparison-chart.png" >}} Figure 1 @@ -52,7 +52,7 @@ varies with the number of those payments combined together. This can be useful be a technique for even greater throughput. -{{< figure alt="states per second" width=80% zoom="/en/images/states-per-second.png" >}} +{{< figure alt="states per second" width=80% src="/en/images/states-per-second.png" >}} Figure 2 @@ -65,7 +65,7 @@ of Figure 3 were achieved using Corda Enterprise 3.0 on **Microsoft Azure** virt with minimal latency between the node VM and the database server VM. -{{< figure alt="comparison chart" width=80% zoom="/en/images/comparison-chart.png" >}} +{{< figure alt="comparison chart" width=80% src="/en/images/comparison-chart.png" >}} Figure 3 @@ -303,7 +303,7 @@ All these machines were 24 core (48 hyper-threads), based on 2x Intel Xeon E5-26 The first test performed was focused on the latency aspect. Load was generated from a single client initialised in a machine that was separate from the ones hosting the Corda nodes and their databases. The load consisted of a pre-defined number of flows (400) that were executed one after the other sequentially. Each one of those flows was initiated on the central exchange node, which was responsible for collecting signatures from all the parties involved and for finalising the transaction. Each of those flows performed a swap of two states between every pair of nodes, thus leading to a Corda transaction with 10 input and 10 output states. During the test setup, the necessary amount of states was initially issued and each one of those states would be swapped once during the test. In order to also measure the impact of transaction resolution, during the test setup each of these states was transferred bilaterally between the nodes in each pair ten times, thus generating a backchain of depth 10. This meant that during every Corda transaction, each node would have to resolve the backchain of the states belonging to the other pairs - so each node would have to resolve 80 states (8 nodes x 10 states each). In order to also measure the scaling with regard to the number of nodes, the exact same test was repeated with a varying number of participants, starting from 4 nodes and going up to 10. The test was also repeated three times with Corda Enterprise versions 4.3, 4.4, and 4.5. The goal was to isolate the benefits from bulk transaction resolution, introduced in version 4.4, and parallelised flows (`CollectSignaturesFlow` / `FinalityFlow`), introduced in version 4.5. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average latency of the flow that performed the asset swap in milliseconds. -{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.3 shows an exponential increase in the latency of the flow as the number of nodes that participate in the transaction is increased. This can be attributed to the following two reasons. Firstly, during the tests the exchange node was performing the `CollectSignaturesFlow` and `FinalityFlow` flows sequentially across the involved nodes, so the more nodes these flows had to iterate over, the more time it took. Secondly, these flows have the capability to trigger the execution of transaction resolution if they identify states for which the node is missing the provenance chain. In Corda Enterprise Edition 4.3, transaction resolution is not performed in bulk - it is performed one state at a time. As a result, every additional node causes a significant amount of extra work to be done. @@ -314,7 +314,7 @@ The main observations from the tests follow below: The second test was focused on the throughput aspect. Load was generated from multiple clients initialised on the machines that were hosting the Corda nodes, which were acting as JMeter servers orchestrated by a JMeter client running on a separate machine. The goal was to saturate the participating Corda nodes and to prevent the single client from becoming the bottleneck. During the test setup, each client issued one state to every node. Each client was then performing one flow at a time, swapping these states between the participating nodes. No backchain was generated as part of this test. As a result, the test was executed only between Corda Enterprise Edition 4.3 and Corda Enterprise Edition 4.5, and with a varying number of nodes ranging from 2 up to 10. Each of the machines driving the load was using 120 concurrent clients, which summed up to 480 concurrent clients in total. Additional measurements were performed with a varying number of clients, in order to ensure that this was the optimal number of clients to saturate the nodes without overloading them. Since the throughput was different depending on the number of participating nodes, the total number of requests was also adjusted accordingly in order to get roughly the same total duration of approximately 20 minutes. In all the scenarios, it was confirmed that the nodes had reached a stable state when the test ended. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average throughput measured in the number of flows completed per second. -{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.5 can achieve a significantly higher throughput when compared to Corda Enterprise Edition 4.3. This can be attributed to the following factors: @@ -336,9 +336,9 @@ Five different variations were tested, as follows: The purpose of this last test was to investigate the effects of these options in both throughput and latency because some of these options introduce trade-offs between these two aspects. To this end, the tests described earlier in this analysis were repeated using the variations listed above. For the latency measurements, 10 nodes were used because, thanks to the low load, there was no expectation for any big interference between nodes on the same machine. For the throughput measurements, only 4 nodes were used in order to avoid any interference between nodes on the same machine due to the high load. The results are shown in the diagrams below - the *x* axis contains the variations used, and the *y* axis shows the average throughput and latency achieved with each variation along with error bars indicating the standard deviation. -{{< figure alt="CE 4.5 variants latency comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_latency.png" >}} +{{< figure alt="CE 4.5 variants latency comparison chart" width=80% src="../resources/performance-testing/4-5_variants_latency.png" >}} -{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_throughput.png" >}} +{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% src="../resources/performance-testing/4-5_variants_throughput.png" >}} The main observations from the test are as follows: * Disabling compression leads to lower throughput and higher latency. This is expected because compression introduces a trade-off between CPU and network bandwidth utilisation and in most cases the network would prove to be a bigger bottleneck. diff --git a/content/en/platform/corda/4.12/enterprise/performance-testing/practical-considerations.md b/content/en/platform/corda/4.12/enterprise/performance-testing/practical-considerations.md index df8676d10df..ad679190e3f 100644 --- a/content/en/platform/corda/4.12/enterprise/performance-testing/practical-considerations.md +++ b/content/en/platform/corda/4.12/enterprise/performance-testing/practical-considerations.md @@ -94,7 +94,7 @@ To collect the output of a JMeter performance run, we need to add listeners to t This listener just lists all the runs that have been completed, one run per row, stating the thread name, sampler label, the sample time in milliseconds, the result status and the latency in milliseconds, among other (usually less useful) fields. -{{< figure alt="jmeter results table" width=80% zoom="../resources/jmeter-results-table.png" >}} +{{< figure alt="jmeter results table" width=80% src="../resources/jmeter-results-table.png" >}} This view is particularly useful when trying out any changes (new flow, new sampler, new installation) to see if it is working at all. The potential outcomes are: @@ -123,7 +123,7 @@ This listener aggregates all the runs for each thread group and the whole test p It also allows plotting these statistics in basic charts and to save the results as a csv file. This is what we use for looking at the performance results on a day to day basis. -{{< figure alt="jmeter results aggregate" width=80% zoom="../resources/jmeter-results-aggregate.png" >}} +{{< figure alt="jmeter results aggregate" width=80% src="../resources/jmeter-results-aggregate.png" >}} This listener has one line for each sampler being run as part of the test plan, and a total line summing up/averaging the results for the whole test plan. diff --git a/content/en/platform/corda/4.12/enterprise/performance-testing/r3-performance-runs.md b/content/en/platform/corda/4.12/enterprise/performance-testing/r3-performance-runs.md index dad0e7b0c9d..ee8dc5867fe 100644 --- a/content/en/platform/corda/4.12/enterprise/performance-testing/r3-performance-runs.md +++ b/content/en/platform/corda/4.12/enterprise/performance-testing/r3-performance-runs.md @@ -32,7 +32,7 @@ The performance network sits behind a firewall that allows incoming connections within the network can connect to each other on a range of ports (Corda Remote Procedure Call (RPC), Corda peer to peer connection (P2P) and JDBC connections to various database servers are all allowed). -{{< figure alt="performance cluster" width=80% zoom="../resources/performance-cluster.png" >}} +{{< figure alt="performance cluster" width=80% src="../resources/performance-cluster.png" >}} A Corda JMeter server instance is running on all 4 nodes and on the notary server. The JMeter client connects to the JMeter server instances via SSH tunnels. As the JMeter servers run within the firewalled network, they are free to diff --git a/content/en/platform/corda/4.12/enterprise/performance-testing/running-jmeter-corda.md b/content/en/platform/corda/4.12/enterprise/performance-testing/running-jmeter-corda.md index 98d99ea3eba..2b7e2a58d11 100644 --- a/content/en/platform/corda/4.12/enterprise/performance-testing/running-jmeter-corda.md +++ b/content/en/platform/corda/4.12/enterprise/performance-testing/running-jmeter-corda.md @@ -54,7 +54,7 @@ interactively either locally or remotely, and view results. The UI has a set of quickly create or load a testplan, control local or remote test runs, and clear any test results collected so far. The latter is particularly important when looking at averages, as old data might skew the results being looked at. -{{< figure alt="jmeter buttons" width=80% zoom="../resources/jmeter-buttons.png" >}} +{{< figure alt="jmeter buttons" width=80% src="../resources/jmeter-buttons.png" >}} The *clear current view* button only clears the data in the currently viewed output collector - if a test plan has several output listeners defined (as in the example above, we have *Aggregate Graph*, *Graph Results* and *View Results in Table*), any collector not currently selected is not affected. *Clear all data* will clear the results from all collectors. diff --git a/content/en/platform/corda/4.12/enterprise/two-phase-finality.md b/content/en/platform/corda/4.12/enterprise/two-phase-finality.md index 5825ea65df3..afdc6710b58 100644 --- a/content/en/platform/corda/4.12/enterprise/two-phase-finality.md +++ b/content/en/platform/corda/4.12/enterprise/two-phase-finality.md @@ -27,7 +27,7 @@ One or more **receivers** use the built-in flow `ReceiveFinalityFlow` to receive Up until Corda 4.10, the finality flow protocol was implemented using a single pass transaction sharing mechanism as depicted below: -{{< figure alt="Conventional Single Phase Finality Protocol" width=100% zoom="./resources/C4-finality-conventional.png" >}} +{{< figure alt="Conventional Single Phase Finality Protocol" width=100% src="./resources/C4-finality-conventional.png" >}} {{< note >}} * Peers only received the finalized transaction after successful notarization. @@ -48,7 +48,7 @@ To address the shortcomings of the conventional protocol, Two Phase Finality int The following diagram illustrates the Two Phase Finality protocol: -{{< figure alt="Two Phase Finality Protocol" width=100% zoom="./resources/C4-finality-optimized-two-phase-finality.png" >}} +{{< figure alt="Two Phase Finality Protocol" width=100% src="./resources/C4-finality-optimized-two-phase-finality.png" >}} The two primary optimizations used within the protocol are: diff --git a/content/en/platform/corda/4.12/enterprise/upgrade-guide.md b/content/en/platform/corda/4.12/enterprise/upgrade-guide.md index e7b74f9ebe7..e516b0b8e13 100644 --- a/content/en/platform/corda/4.12/enterprise/upgrade-guide.md +++ b/content/en/platform/corda/4.12/enterprise/upgrade-guide.md @@ -49,7 +49,7 @@ The different colors in the diagram indicate the elements used in each version. The Corda 4.11 transaction verifier has also been preserved in an external process to allow Corda 4.11 transactions to be verified by Corda 4.12. -{{< figure alt="Corda 4.12 vs Corda 4.11" width=75% height=75% zoom="resources/corda412vs411.png" figcaption="Corda 4.12 vs Corda 4.11">}} +{{< figure alt="Corda 4.12 vs Corda 4.11" width=75% height=75% src="resources/corda412vs411.png" figcaption="Corda 4.12 vs Corda 4.11">}} ## Upgrade scenarios diff --git a/content/en/platform/corda/4.8/enterprise/api-core-types.md b/content/en/platform/corda/4.8/enterprise/api-core-types.md index ba154ca7710..6ec2de99f94 100644 --- a/content/en/platform/corda/4.8/enterprise/api-core-types.md +++ b/content/en/platform/corda/4.8/enterprise/api-core-types.md @@ -66,11 +66,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="./resources/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="./resources/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="./resources/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="./resources/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/platform/corda/4.8/enterprise/apps/bankinabox/user-interface/how-to.md b/content/en/platform/corda/4.8/enterprise/apps/bankinabox/user-interface/how-to.md index 8e645bafab2..e682b93f880 100644 --- a/content/en/platform/corda/4.8/enterprise/apps/bankinabox/user-interface/how-to.md +++ b/content/en/platform/corda/4.8/enterprise/apps/bankinabox/user-interface/how-to.md @@ -70,7 +70,7 @@ Follow these steps to create a new customer profile. When the customer profile is created, they will not have any accounts - you will have to create them. Learn how under [Creating accounts](#create-a-current-account). {{< /note >}} -{{< figure alt="Create customer profile" width=80% zoom="/en/gifs/create-customer-biab-1.0.gif" >}} +{{< figure alt="Create customer profile" width=80% src="/en/gifs/create-customer-biab-1.0.gif" >}} ### Create a Current account @@ -94,7 +94,7 @@ When the customer profile is created, they will not have any accounts - you will 7. When an account is created, it is in **PENDING** status. This must be changed to **ACTIVE** for a customer to be able to interact with and use the account. See [Change an account status](#change-an-account-status) for more information. -{{< figure alt="Create account" width=80% zoom="/en/gifs/create-current-account-biab-1.0.gif" >}} +{{< figure alt="Create account" width=80% src="/en/gifs/create-current-account-biab-1.0.gif" >}} ### Create a Savings account @@ -140,7 +140,7 @@ An account has three statuses: **PENDING**, **ACTIVE**, and **SUSPENDED**. When If the account needs to be suspended, follow the same steps but select **SUSPENDED**. -{{< figure alt="Set account status" width=80% zoom="/en/gifs/set-account-status-biab-1.0.gif" >}} +{{< figure alt="Set account status" width=80% src="/en/gifs/set-account-status-biab-1.0.gif" >}} ### Assign or revoke a user role @@ -163,7 +163,7 @@ To assign a user role, follow these steps: 5. Click **Revoke**. A message will appear indicating that the user role was assigned successfully. -{{< figure alt="Assign role" width=80% zoom="/en/gifs/assign-a-role-biab-1.0.gif" >}} +{{< figure alt="Assign role" width=80% src="/en/gifs/assign-a-role-biab-1.0.gif" >}} #### Revoke a user role @@ -179,7 +179,7 @@ To revoke a user role, follow these steps: 5. Click **Save**. A message will appear indicating that the user role was revoked successfully. -{{< figure alt="Revoke role" width=80% zoom="/en/gifs/revoke-role-biab-1.0.gif" >}} +{{< figure alt="Revoke role" width=80% src="/en/gifs/revoke-role-biab-1.0.gif" >}} ### Issue a loan @@ -195,7 +195,7 @@ Once the account has been set to **ACTIVE**, you will have the ability to issue A loan account is created when a loan has been issued successfully. -{{< figure alt="Issue loan" width=80% zoom="/en/gifs/issue-loan-biab-1.0.gif" >}} +{{< figure alt="Issue loan" width=80% src="/en/gifs/issue-loan-biab-1.0.gif" >}} ### Approve overdrafts @@ -215,7 +215,7 @@ To approve an overdraft, follow these steps. Overdrafts can be approved whether the account is **PENDING**, **ACTIVE**, or **SUSPENDED**. {{< /note >}} -{{< figure alt="Approve overdraft" width=80% zoom="/en/gifs/approve-overdraft-biab-1.0.gif" >}} +{{< figure alt="Approve overdraft" width=80% src="/en/gifs/approve-overdraft-biab-1.0.gif" >}} ### Deposit money to an account @@ -230,7 +230,7 @@ Follow these steps to deposit money to a customer account. 4. Click **Save**. You will receive a message indicating that the deposit was successful. -{{< figure alt="Deposit" width=80% zoom="/en/gifs/deposit-biab-1.0.gif" >}} +{{< figure alt="Deposit" width=80% src="/en/gifs/deposit-biab-1.0.gif" >}} ### Register as a user on Bank in a Box @@ -251,7 +251,7 @@ You must be registered as a **Customer** or **Admin** on Bank in a Box to perfor 5. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update customer profile @@ -284,7 +284,7 @@ An **Admin user** can set an account's **Withdrawal daily limit** or **Transfer 2. Click **Save** when you have entered the desired limits. A message will appear indicating that the limits have been saved successfully. -{{< figure alt="Set withdrawal and transfer limits - admin" width=80% zoom="/en/gifs/set-limits-admin-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - admin" width=80% src="/en/gifs/set-limits-admin-biab-1.0.gif" >}} ## Customer tasks @@ -309,12 +309,12 @@ Follow these steps to create a new intrabank payment. 6. Click **Save**. You will receive a notification indicating that the payment was created successfully. You will also receive notifications indicating any changes in your account balances. -{{< figure alt="Create intrabank payment" width=80% zoom="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} +{{< figure alt="Create intrabank payment" width=80% src="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} After making a payment, you can view the details of this transaction on the Transactions screen. -{{< figure alt="View transaction" width="800" width=80% zoom="/en/gifs/view-transaction-biab-1.0.gif" >}} +{{< figure alt="View transaction" width="800" width=80% src="/en/gifs/view-transaction-biab-1.0.gif" >}} ### Create a recurring payment @@ -338,7 +338,7 @@ Follow these steps to create a recurring payment: 3. You will be taken back to the **Recurring payments screen** where you will receive a message indicating that the recurring payment was created successfully. -{{< figure alt="Recurring payment" width=80% zoom="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} +{{< figure alt="Recurring payment" width=80% src="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} {{< note >}} This payment will not appear on the **Recurring payments screen** until the first iteration has occurred. @@ -367,7 +367,7 @@ You must be registered as a Customer or Admin on Bank in a Box to perform tasks. 7. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update a customer profile @@ -406,4 +406,4 @@ To set these limits as a **Customer**, follow these steps. 4. Click **Save**. You will be taken back to the Account page where you will receive a message indicating that the limits have been updated successfully. -{{< figure alt="Set withdrawal and transfer limits - customer" width=80% zoom="/en/gifs/set-limits-customer-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - customer" width=80% src="/en/gifs/set-limits-customer-biab-1.0.gif" >}} diff --git a/content/en/platform/corda/4.8/enterprise/contract-irs.md b/content/en/platform/corda/4.8/enterprise/contract-irs.md index e6db718a0bc..a525fcad7e6 100644 --- a/content/en/platform/corda/4.8/enterprise/contract-irs.md +++ b/content/en/platform/corda/4.8/enterprise/contract-irs.md @@ -45,7 +45,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="./resources/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="./resources/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/platform/corda/4.8/enterprise/cordapp-advanced-concepts.md b/content/en/platform/corda/4.8/enterprise/cordapp-advanced-concepts.md index 79174bd0a04..19fed9644d2 100644 --- a/content/en/platform/corda/4.8/enterprise/cordapp-advanced-concepts.md +++ b/content/en/platform/corda/4.8/enterprise/cordapp-advanced-concepts.md @@ -71,7 +71,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="./resources/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="./resources/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/platform/corda/4.8/enterprise/cordapps/api-flows.md b/content/en/platform/corda/4.8/enterprise/cordapps/api-flows.md index ad01e726f58..d6b71c59e6d 100644 --- a/content/en/platform/corda/4.8/enterprise/cordapps/api-flows.md +++ b/content/en/platform/corda/4.8/enterprise/cordapps/api-flows.md @@ -91,7 +91,7 @@ The `initiator`: You can visualize the work performed by initiator like this: -{{< figure alt="flow overview" width=80% zoom="../resources/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="../resources/flow-overview.png" >}} ## Responder flow class example diff --git a/content/en/platform/corda/4.8/enterprise/cordapps/api-states.md b/content/en/platform/corda/4.8/enterprise/cordapps/api-states.md index 6461899e010..813f8fec2d2 100644 --- a/content/en/platform/corda/4.8/enterprise/cordapps/api-states.md +++ b/content/en/platform/corda/4.8/enterprise/cordapps/api-states.md @@ -62,7 +62,7 @@ states evolve in a straight line by superseding themselves. You can visualize the hierarchy like this: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/platform/corda/4.8/enterprise/cordapps/cordapp-overview.md b/content/en/platform/corda/4.8/enterprise/cordapps/cordapp-overview.md index 87df4a718ac..d4fe98948be 100644 --- a/content/en/platform/corda/4.8/enterprise/cordapps/cordapp-overview.md +++ b/content/en/platform/corda/4.8/enterprise/cordapps/cordapp-overview.md @@ -31,7 +31,7 @@ CorDapps are: A Corda Distributed Application (CorDapp) solves a specific problem using the Corda framework. CorDapps are stored on Corda nodes and executed on the Corda network. This *distributes* the app, allowing it to run on multiple systems simultaneously—unlike traditional apps, which utilize one dedicated system to achieve an assigned task. CorDapps let nodes communicate with each other to reach agreement on updates to the ledger by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="../resources/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="../resources/node-diagram.png" >}} ## Glossary diff --git a/content/en/platform/corda/4.8/enterprise/cordapps/deterministic-jvm.md b/content/en/platform/corda/4.8/enterprise/cordapps/deterministic-jvm.md index 667e19d6ae6..0ce37a2b14a 100644 --- a/content/en/platform/corda/4.8/enterprise/cordapps/deterministic-jvm.md +++ b/content/en/platform/corda/4.8/enterprise/cordapps/deterministic-jvm.md @@ -75,7 +75,7 @@ severity `ERROR` will prevent execution. The sandbox has a configuration that applies to the execution of a specific runnable. This configuration, on a higher level, contains a set of rules, definition providers and emitters. -{{< figure alt="djvm overview" width=80% zoom="../resources/djvm-overview.png" >}} +{{< figure alt="djvm overview" width=80% src="../resources/djvm-overview.png" >}} The set of rules is what defines the constraints posed on the runtime environment. A rule can act on three different levels, namely on a type-, member- or instruction-level. The set of rules get processed and validated by the `RuleValidator` prior to execution. diff --git a/content/en/platform/corda/4.8/enterprise/cordapps/upgrading-cordapps.md b/content/en/platform/corda/4.8/enterprise/cordapps/upgrading-cordapps.md index b7d163c288a..d1c460e7fc2 100644 --- a/content/en/platform/corda/4.8/enterprise/cordapps/upgrading-cordapps.md +++ b/content/en/platform/corda/4.8/enterprise/cordapps/upgrading-cordapps.md @@ -71,7 +71,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="../resources/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="../resources/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/platform/corda/4.8/enterprise/financial-model.md b/content/en/platform/corda/4.8/enterprise/financial-model.md index 4cd07bcd37a..503b12c52b7 100644 --- a/content/en/platform/corda/4.8/enterprise/financial-model.md +++ b/content/en/platform/corda/4.8/enterprise/financial-model.md @@ -92,6 +92,6 @@ countable (in cents), barrels of oil are fungible and countable (oil from two sm container), shares of the same class in a specific company are fungible and countable, and so on. This diagram illustrates the complete contract state hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Corda provides two packages: a core library and a finance model-specific library. You can re-use or extend the finance types directly, or write your own by extending the base types from the core library. diff --git a/content/en/platform/corda/4.8/enterprise/health-survey.md b/content/en/platform/corda/4.8/enterprise/health-survey.md index f76bc87ac5a..1fb670050a6 100644 --- a/content/en/platform/corda/4.8/enterprise/health-survey.md +++ b/content/en/platform/corda/4.8/enterprise/health-survey.md @@ -116,7 +116,7 @@ The Corda Health Survey currently does not support testing RPC communication if The tool generates the archive of the collected files in the same directory it is ran in. The names are in the format: `report-date-time.zip` -{{< figure alt="health survey photo" width=80% zoom="resources/health-survey-photo.png" >}} +{{< figure alt="health survey photo" width=80% src="resources/health-survey-photo.png" >}} ## Deployment health check diff --git a/content/en/platform/corda/4.8/enterprise/key-concepts-consensus.md b/content/en/platform/corda/4.8/enterprise/key-concepts-consensus.md index a6be0494c04..54151e5086a 100644 --- a/content/en/platform/corda/4.8/enterprise/key-concepts-consensus.md +++ b/content/en/platform/corda/4.8/enterprise/key-concepts-consensus.md @@ -49,7 +49,7 @@ transferring a treasury bond, the bond transfer is only valid if: Walking the chain for this transaction would look like this: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a node may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer. The @@ -68,7 +68,7 @@ proposals: Both transactions will achieve validity consensus, yet Alice has managed to “double-spend” her USD to get double the amount of GBP and EUR: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/platform/corda/4.8/enterprise/key-concepts-contracts.md b/content/en/platform/corda/4.8/enterprise/key-concepts-contracts.md index 3f329f39c29..f71c195999d 100644 --- a/content/en/platform/corda/4.8/enterprise/key-concepts-contracts.md +++ b/content/en/platform/corda/4.8/enterprise/key-concepts-contracts.md @@ -55,7 +55,7 @@ transaction gathers all the required signatures, it can't be executed unless it Each transaction [state]({{< relref "key-concepts-states.md" >}}) specifies a *contract type*. The contract specified takes the transaction as input, and determines if the transaction is valid based on the contract's internal rules. The contract must evaluate every input state and every output state. -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code can: * Check the number of inputs, outputs, commands, or attachments. diff --git a/content/en/platform/corda/4.8/enterprise/key-concepts-ecosystem.md b/content/en/platform/corda/4.8/enterprise/key-concepts-ecosystem.md index 89719ef90de..c3c434ff8dc 100644 --- a/content/en/platform/corda/4.8/enterprise/key-concepts-ecosystem.md +++ b/content/en/platform/corda/4.8/enterprise/key-concepts-ecosystem.md @@ -32,7 +32,7 @@ title: Networks, identity, and discovery ## What is a network? On Corda, people and business interact by communicating over a peer-to-peer network of [Corda nodes]({{< relref "key-concepts-node.md" >}}). Each node represents a legal entity running Corda and one or more Corda distributed applications, known as [CorDapps]({{< relref "cordapps/cordapp-overview.md" >}}). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} Corda is different from other distributed ledgers because all communication between nodes is point-to-point, and only shared on a need-to-know basis. It is also encrypted using transport-layer security. There are *no global broadcasts* to all parties on a network, but all of the nodes in a network can send messages directly to other nodes. If the recipient is offline, the message waits in an outbound queue until they are online again—just like an email. ## Join a network diff --git a/content/en/platform/corda/4.8/enterprise/key-concepts-flows.md b/content/en/platform/corda/4.8/enterprise/key-concepts-flows.md index 1a68808894e..b33c6ed1c14 100644 --- a/content/en/platform/corda/4.8/enterprise/key-concepts-flows.md +++ b/content/en/platform/corda/4.8/enterprise/key-concepts-flows.md @@ -35,7 +35,7 @@ must specify what information needs to be sent, to which counterparties, and in Here is a visualisation of Alice and Bob agreeing a ledger update using this process: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -44,7 +44,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is a diagram showing the flow's steps used between Alice and Bob to perform the ledger update: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/platform/corda/4.8/enterprise/key-concepts-ledger.md b/content/en/platform/corda/4.8/enterprise/key-concepts-ledger.md index d4b7dd8f46d..2ef78cf0458 100644 --- a/content/en/platform/corda/4.8/enterprise/key-concepts-ledger.md +++ b/content/en/platform/corda/4.8/enterprise/key-concepts-ledger.md @@ -39,7 +39,7 @@ loan are Alice and Bob, then they are the only nodes that ever see or store this This diagram shows a network with five nodes (Alice, Bob, Carl, Demi, and Ed). Each numbered circle on an intersection represents a fact shared between two or more nodes: -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} In the diagram, facts 1 and 7 are known by both Alice and Bob. Alice only shares facts with Bob, Alice doesn't share any facts with Carl, Demi, or Ed. @@ -56,7 +56,7 @@ each node maintains its own vault, which contains all of its known facts. You can think of a vault as being a database or simple table. In this diagram, facts 1 and 7 appear on both Alice's vault and Bob's vault, and are therefore shared facts: -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} When multiple nodes on a network share an evolving fact, the changes to the fact update at the same time in each node's vault. This means that Alice and Bob will both see an *identical version* of shared facts 1 and 7. diff --git a/content/en/platform/corda/4.8/enterprise/key-concepts-node.md b/content/en/platform/corda/4.8/enterprise/key-concepts-node.md index 5aaecaf55f0..565ed3fe3aa 100644 --- a/content/en/platform/corda/4.8/enterprise/key-concepts-node.md +++ b/content/en/platform/corda/4.8/enterprise/key-concepts-node.md @@ -35,7 +35,7 @@ title: Nodes A Corda node runs within a Java Virtual Machine (JVM) runtime environment with a [unique network identity]({{< relref "key-concepts-ecosystem.md#node-identities" >}}). JVM runtime environments provide a consistent platform on which you can run and deploy Java applications, such as Corda services and CorDapps. Here is a visualization of the node’s internal architecture: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: diff --git a/content/en/platform/corda/4.8/enterprise/key-concepts-states.md b/content/en/platform/corda/4.8/enterprise/key-concepts-states.md index 473ef5f1b81..47376319387 100644 --- a/content/en/platform/corda/4.8/enterprise/key-concepts-states.md +++ b/content/en/platform/corda/4.8/enterprise/key-concepts-states.md @@ -35,7 +35,7 @@ You can use states to represent any type of data, and any kind of fact. For exam This state represents an IOU—an agreement that Alice owes Bob £10: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} In addition to information about the fact, the state contains a reference to the **[contract]({{< relref "key-concepts-contracts.md" >}})**. Contracts govern the evolution of states. @@ -47,14 +47,14 @@ When a fact changes, one of the state's participants creates a new state and mar For example, if Alice pays Bob £5, the state sequence would be: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a **vault**. This is the node's database used to store current and historic states where the node is a participant. For example: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} From each node's point of view, the ledger is the current (non-historic) states where that node is a participant. diff --git a/content/en/platform/corda/4.8/enterprise/key-concepts-tearoffs.md b/content/en/platform/corda/4.8/enterprise/key-concepts-tearoffs.md index 6efa76dd3e7..4ab14f8e2b6 100644 --- a/content/en/platform/corda/4.8/enterprise/key-concepts-tearoffs.md +++ b/content/en/platform/corda/4.8/enterprise/key-concepts-tearoffs.md @@ -39,7 +39,7 @@ Merkle trees split transactions into "leaves". Each leaf contains either an input, an output, a command, or an attachment. The final nested tree structure also contains the other fields of the transaction, such as the time window, the notary, and the required signers. The only component type that requires two trees instead of one is the command, which is split into command data and required signers for visibility purposes. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} Corda uses one nested Merkle tree per component type. A component sub-tree is generated for each component type (for example, inputs, outputs, or attachments). The roots of these sub-trees @@ -65,7 +65,7 @@ obtained belongs to that particular transaction. In this example, assume that only the first command should be visible to the oracle. You must provide guarantees that all the commands the oracle needs to sign are visible to the oracle entity, but no other data. The transaction would be represented in the Merkle tree structure like this: -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} The blue nodes and `H(c2)` are provided to the oracle service, while the black ones are omitted. The oracle needs `H(c2)` so it can compute `H(commandData)` without being to able to see the second command. At the same time, this ensures that `CommandData1` is part of the transaction. All signers are visible as @@ -79,4 +79,4 @@ To send the same transaction to a non-validating notary, hide all components apart from input states, time window, and the notary information. This data is enough for the notary to know which input states to check for double-spending, if the time-window is valid, and if the transaction is being notarized by the correct notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/platform/corda/4.8/enterprise/key-concepts-time-windows.md b/content/en/platform/corda/4.8/enterprise/key-concepts-time-windows.md index b7e5f6a3cb4..e53d513b3e2 100644 --- a/content/en/platform/corda/4.8/enterprise/key-concepts-time-windows.md +++ b/content/en/platform/corda/4.8/enterprise/key-concepts-time-windows.md @@ -46,7 +46,7 @@ trade, or requesting human sign-off. Times in transactions are specified as time *windows*, not absolute times. Time windows can be open-ended, and specify only “before” **or** “after”, or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} When both a before and an after time are included the transaction occurred at some point within that time window. diff --git a/content/en/platform/corda/4.8/enterprise/key-concepts-transactions.md b/content/en/platform/corda/4.8/enterprise/key-concepts-transactions.md index ef312b96b14..8f31a984f0a 100644 --- a/content/en/platform/corda/4.8/enterprise/key-concepts-transactions.md +++ b/content/en/platform/corda/4.8/enterprise/key-concepts-transactions.md @@ -37,7 +37,7 @@ Every [state]({{< relref "key-concepts-states.md" >}}) is *immutable*—it can't Here is an example of a transaction with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type. Transactions can: * Include different types of states representing multiple financial instruments, such as cash or bonds. @@ -65,21 +65,21 @@ Input state references consist of: You can see how this works in this example transaction: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} ## Committing transactions to the ledger Initially, a transaction is only a proposal to update the ledger. It represents the future state of the ledger desired by the transaction builders. -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To be committed to the ledger, the transaction must receive signatures from all the *required signers*. Each required signer appends their signature to the transaction to approve the proposal. -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If the transaction gathers the required signatures, it is committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions. @@ -121,7 +121,7 @@ For example, suppose Alice uses $5 cash to pay off $5 of an IOU with Bob. This transaction contains a *settlement command* which reduces the amount outstanding on the IOU, and a *payment command* which changes the ownership of $5 from Alice to Bob. It also has two supporting attachments, and is notarized by `NotaryClusterA` if the notary pool receives it within the specified time window: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -145,7 +145,7 @@ listed in the commands, you get the list of the transaction’s required signers This situation would look like this: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/platform/corda/4.8/enterprise/key-concepts-vault.md b/content/en/platform/corda/4.8/enterprise/key-concepts-vault.md index 1a34d5593bf..73f20f5684e 100644 --- a/content/en/platform/corda/4.8/enterprise/key-concepts-vault.md +++ b/content/en/platform/corda/4.8/enterprise/key-concepts-vault.md @@ -47,7 +47,7 @@ The vault supports the management of data in both authoritative **on-ledger** fo This diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} You can see: diff --git a/content/en/platform/corda/4.8/enterprise/network/cipher-suites.md b/content/en/platform/corda/4.8/enterprise/network/cipher-suites.md index b20cb12ae40..64dd45f1ddc 100644 --- a/content/en/platform/corda/4.8/enterprise/network/cipher-suites.md +++ b/content/en/platform/corda/4.8/enterprise/network/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates]({{< relref "permissioning.md" >}})): -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/platform/corda/4.8/enterprise/network/network-builder.md b/content/en/platform/corda/4.8/enterprise/network/network-builder.md index 531deb6a3b3..8f70f2b4345 100644 --- a/content/en/platform/corda/4.8/enterprise/network/network-builder.md +++ b/content/en/platform/corda/4.8/enterprise/network/network-builder.md @@ -17,7 +17,7 @@ title: Corda Network Builder The Corda Network Builder is a tool for building Corda networks for testing purposes. It leverages Docker and containers to abstract the complexity of managing a distributed network away from the user. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} The network you build will either be made up of local `Docker` nodes *or* of nodes spread across Azure containers. For each node a separate Docker image is built based on [corda/corda-zulu-java1.8-4.4](https://hub.docker.com/r/corda/corda-zulu-java1.8-4.4). diff --git a/content/en/platform/corda/4.8/enterprise/network/permissioning.md b/content/en/platform/corda/4.8/enterprise/network/permissioning.md index 9d9f129243a..0aa8ff0f496 100644 --- a/content/en/platform/corda/4.8/enterprise/network/permissioning.md +++ b/content/en/platform/corda/4.8/enterprise/network/permissioning.md @@ -42,7 +42,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/platform/corda/4.8/enterprise/node/collaborative-recovery/deployment-and-operations.md b/content/en/platform/corda/4.8/enterprise/node/collaborative-recovery/deployment-and-operations.md index 591dd6f2899..3ab0194916c 100644 --- a/content/en/platform/corda/4.8/enterprise/node/collaborative-recovery/deployment-and-operations.md +++ b/content/en/platform/corda/4.8/enterprise/node/collaborative-recovery/deployment-and-operations.md @@ -90,7 +90,7 @@ The space complexities are outlined below: You can see a suggested high-level, disaster recovery setup in the diagram below. -{{< figure alt="Suggested Disaster Recovery Setup" width=80% zoom="../../resources/collaborative-recovery/dr-setup.png" >}} +{{< figure alt="Suggested Disaster Recovery Setup" width=80% src="../../resources/collaborative-recovery/dr-setup.png" >}} The exact setup you choose is likely to be influenced by your organisation and business requirements, but the key points are: diff --git a/content/en/platform/corda/4.8/enterprise/node/collaborative-recovery/introduction-cr.md b/content/en/platform/corda/4.8/enterprise/node/collaborative-recovery/introduction-cr.md index 4fddec78d1f..b13e11e1581 100644 --- a/content/en/platform/corda/4.8/enterprise/node/collaborative-recovery/introduction-cr.md +++ b/content/en/platform/corda/4.8/enterprise/node/collaborative-recovery/introduction-cr.md @@ -153,7 +153,7 @@ inbound / outbound reconciliations and also supports different throttling techni A high-level, peer-to-peer reconciliation flow is depicted in the diagram below. **LedgerSync** can run multiple reconciliations concurrently, up to the limit configured by the user. -{{< figure alt="Peer-to-Peer Reconciliation Flow" width=80% zoom="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} +{{< figure alt="Peer-to-Peer Reconciliation Flow" width=80% src="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} ### LedgerRecover @@ -176,7 +176,7 @@ supports different types of throttling to prevent accidental abuse of the functi A high-level, peer-to-peer automatic recovery flow is depicted in the diagram below. -{{< figure alt="Peer-to-Peer Automatic Recovery Flow" width=80% zoom="../../resources/collaborative-recovery/automatic-ledger-recover-flow.png" >}} +{{< figure alt="Peer-to-Peer Automatic Recovery Flow" width=80% src="../../resources/collaborative-recovery/automatic-ledger-recover-flow.png" >}} {{< attention >}} Even though the recovery flow contains the word "automatic" in its name, it can only be started manually. @@ -195,7 +195,7 @@ the import has been stopped halfway through. A high-level, peer-to-peer manual recovery flow is depicted in the diagram below. -{{< figure alt="Peer-to-Peer Manual Recovery Flow" width=80% zoom="../../resources/collaborative-recovery/manual-ledger-recover-flow.png" >}} +{{< figure alt="Peer-to-Peer Manual Recovery Flow" width=80% src="../../resources/collaborative-recovery/manual-ledger-recover-flow.png" >}} ### Supported disaster recovery scenarios diff --git a/content/en/platform/corda/4.8/enterprise/node/collaborative-recovery/ledger-sync.md b/content/en/platform/corda/4.8/enterprise/node/collaborative-recovery/ledger-sync.md index 1169aff206e..f48554548ca 100644 --- a/content/en/platform/corda/4.8/enterprise/node/collaborative-recovery/ledger-sync.md +++ b/content/en/platform/corda/4.8/enterprise/node/collaborative-recovery/ledger-sync.md @@ -28,7 +28,7 @@ All reconciliations are added to a bounded execution pool, which is configurable This means the node that requested the reconciliation will be notified if the responding node has transactions that the requesting node does not. The responding node will not be notified if the requesting node has transactions that the responding node does not. -{{< figure alt="LedgerSync Flow" width=80% zoom="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} +{{< figure alt="LedgerSync Flow" width=80% src="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} ### Integration with Archiving diff --git a/content/en/platform/corda/4.8/enterprise/node/component-topology.md b/content/en/platform/corda/4.8/enterprise/node/component-topology.md index 02dbaf1499b..13fa0bb2c62 100644 --- a/content/en/platform/corda/4.8/enterprise/node/component-topology.md +++ b/content/en/platform/corda/4.8/enterprise/node/component-topology.md @@ -33,7 +33,7 @@ The key node components and services are: * The Corda firewall -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" figcaption="Node internal architecture.">}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" figcaption="Node internal architecture.">}} ### CorDapps @@ -83,14 +83,14 @@ Nodes communicate with other nodes using asynchronous AMQP/TLS 1.2 protocols. HT Nodes communicate with client applications using RPC calls. -{{< figure alt="overview" width=80% zoom="../resources/overview.png" >}} +{{< figure alt="overview" width=80% src="../resources/overview.png" >}} ## Typical node deployments In most cases, nodes are deployed with this architecture: -{{< figure alt="nodebridgefloat nbrs" width=80% zoom="../resources/nodebridgefloat_nbrs.png" figcaption="A typical node deployment.">}} +{{< figure alt="nodebridgefloat nbrs" width=80% src="../resources/nodebridgefloat_nbrs.png" figcaption="A typical node deployment.">}} Most production deployments of Corda Enterprise include nodes, vaults, and firewalls. diff --git a/content/en/platform/corda/4.8/enterprise/node/corda-firewall-component.md b/content/en/platform/corda/4.8/enterprise/node/corda-firewall-component.md index e3de1745061..6fa396941d9 100644 --- a/content/en/platform/corda/4.8/enterprise/node/corda-firewall-component.md +++ b/content/en/platform/corda/4.8/enterprise/node/corda-firewall-component.md @@ -140,7 +140,7 @@ Artemis with the node as TLS endpoint and to have the outgoing packets use the i Typically this should only be used for easy development, or for organisations evaluating on Open Source Corda, where this is the only available option: -{{< figure alt="node embedded bridge" width=80% zoom="/en/images/node_embedded_bridge.png" >}} +{{< figure alt="node embedded bridge" width=80% src="/en/images/node_embedded_bridge.png" >}} ### Node + Combined Bridge/Float (no DMZ) @@ -170,7 +170,7 @@ Then configure an all-in-one bridge to point at this node’s `messagingServerAd {{< /note >}} -{{< figure alt="simple bridge" width=80% zoom="/en/images/simple_bridge.png" >}} +{{< figure alt="simple bridge" width=80% src="/en/images/simple_bridge.png" >}} #### node.conf @@ -238,7 +238,7 @@ key, the tunnel link should use a private set of link specific keys and certific dynamically with the official TLS key when activated via the tunnel and this key will never be stored in the DMZ: {{< /note >}} -{{< figure alt="node bridge float" width=80% zoom="/en/images/node_bridge_float.png" >}} +{{< figure alt="node bridge float" width=80% src="/en/images/node_bridge_float.png" >}} #### node.conf @@ -326,7 +326,7 @@ Some organisations require dynamic outgoing connections to operate via a SOCKS p by adding extra information to the `outboundConfig` section of the bridge process. A simplified example deployment is shown here to highlight the option: -{{< figure alt="socks proxy" width=80% zoom="/en/images/socks_proxy.png" >}} +{{< figure alt="socks proxy" width=80% src="/en/images/socks_proxy.png" >}} #### node.conf @@ -426,7 +426,7 @@ Highlighted in the diagram is the addition of the `haConfig` section to point at addresses in the `alternateArtemisAddresses` to allow node failover and in the `floatAddresses` to point at a pool of DMZ float processes. -{{< figure alt="ha nodes" width=80% zoom="/en/images/ha_nodes.png" >}} +{{< figure alt="ha nodes" width=80% src="/en/images/ha_nodes.png" >}} #### node.conf @@ -563,7 +563,7 @@ It is possible to allow two or more Corda nodes (HA and/or non-HA) handle outgoi an external Artemis messaging broker which can be easily configured using the ha-tool. For more information, please see HA Utilities. While this example is the simplest deployment possible with a shared bridge, any other configuration previously presented can be created. -{{< figure alt="multiple nodes no ha" width=80% zoom="/en/images/multiple_nodes_no_ha.png" >}} +{{< figure alt="multiple nodes no ha" width=80% src="/en/images/multiple_nodes_no_ha.png" >}} #### bank-a-node.conf diff --git a/content/en/platform/corda/4.8/enterprise/node/corda-firewall-configuration-file.md b/content/en/platform/corda/4.8/enterprise/node/corda-firewall-configuration-file.md index c4314ff9c5b..ac2df8c27ae 100644 --- a/content/en/platform/corda/4.8/enterprise/node/corda-firewall-configuration-file.md +++ b/content/en/platform/corda/4.8/enterprise/node/corda-firewall-configuration-file.md @@ -132,14 +132,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -152,7 +152,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/platform/corda/4.8/enterprise/node/deploy/env-prod-test.md b/content/en/platform/corda/4.8/enterprise/node/deploy/env-prod-test.md index 3a116f69b86..a71f307c814 100644 --- a/content/en/platform/corda/4.8/enterprise/node/deploy/env-prod-test.md +++ b/content/en/platform/corda/4.8/enterprise/node/deploy/env-prod-test.md @@ -33,12 +33,12 @@ There are alternative approaches to how these components are deployed. For the p When deploying Corda Enterprise in a testing environment the Node, Bridge, and Float components should be deployed in a non-HA configuration as shown in the following diagram. -{{< figure alt="nonha" width=80% zoom="../../resources/nonha.png" >}} +{{< figure alt="nonha" width=80% src="../../resources/nonha.png" >}} When deploying Corda Enterprise in a production environment, the Node, Bridge, and Float components should be deployed in a high-availability configuration. -{{< figure alt="ha" width=80% zoom="../../resources/ha.png" >}} +{{< figure alt="ha" width=80% src="../../resources/ha.png" >}} ### Deployment details @@ -206,7 +206,7 @@ This is a sample `node.conf` which details a configuration connecting to a Corda In a bank environment there will typically be several layers of security protecting the firms data. -{{< figure alt="cordarch" width=80% zoom="../../resources/cordarch.png" >}} +{{< figure alt="cordarch" width=80% src="../../resources/cordarch.png" >}} *Network Authentication* @@ -220,7 +220,7 @@ In a bank environment there will typically be several layers of security protect * Corda PKI Authentication issued by Corda Network can link the Node and Bridge i.e. the red keys indicated below truststore and sslkeystore * Local PKI Authentication issued by separate CA will link the Bridge and Float i.e the purple keys indicated below trust and Bridge. -{{< figure alt="firewallpki" width=80% zoom="../../resources/firewallpki.png" >}} +{{< figure alt="firewallpki" width=80% src="../../resources/firewallpki.png" >}} The key thing is to look at this from the perspective of a bank implementing these Corda and Local PKI keys. @@ -375,7 +375,7 @@ Administrative logins with the Corda node happen via ssh whose port is configure The following image may be helpful in ensuring alignment between the Node, Bridge and Float configuration files. -{{< figure alt="CordaFirewallConfigAlign" width=80% zoom="../../resources/CordaFirewallConfigAlign.png" >}} +{{< figure alt="CordaFirewallConfigAlign" width=80% src="../../resources/CordaFirewallConfigAlign.png" >}} {{< note >}} **p2pAddress** reflects the **publicly accessible address**, which may or may not be the Float inboundConfig.listeningAddress. If there is an internet firewall configured in front of the Float then ask the Network Administrator for the public address that routes to the Float’s **listeningAddress**, and use that public address for your **p2pAddress**. diff --git a/content/en/platform/corda/4.8/enterprise/node/deploy/hot-cold-deployment.md b/content/en/platform/corda/4.8/enterprise/node/deploy/hot-cold-deployment.md index 76a99fa7320..0b1221c7a26 100644 --- a/content/en/platform/corda/4.8/enterprise/node/deploy/hot-cold-deployment.md +++ b/content/en/platform/corda/4.8/enterprise/node/deploy/hot-cold-deployment.md @@ -36,7 +36,7 @@ resources for both **Microsoft Azure** and **Amazon Web Services**. The image be result from following the guide. There will be two Corda Enterprise nodes, one active and the other inactive. Each node will represent the same legal identity inside the Corda network. Both will share a database and a network file system. -{{< figure alt="hot cold" width=80% zoom="../../resources/hot-cold.png" >}} +{{< figure alt="hot cold" width=80% src="../../resources/hot-cold.png" >}} ## Configuring the load balancer diff --git a/content/en/platform/corda/4.8/enterprise/node/operating/node-administration.md b/content/en/platform/corda/4.8/enterprise/node/operating/node-administration.md index 6a962fa9ea1..390a6f898d9 100644 --- a/content/en/platform/corda/4.8/enterprise/node/operating/node-administration.md +++ b/content/en/platform/corda/4.8/enterprise/node/operating/node-administration.md @@ -245,7 +245,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ### Monitoring via Graphite diff --git a/content/en/platform/corda/4.8/enterprise/node/operating/node-database-tables.md b/content/en/platform/corda/4.8/enterprise/node/operating/node-database-tables.md index 91b6afc2d6c..c63041de45a 100644 --- a/content/en/platform/corda/4.8/enterprise/node/operating/node-database-tables.md +++ b/content/en/platform/corda/4.8/enterprise/node/operating/node-database-tables.md @@ -42,7 +42,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more in [Network map]({{< relref "../../network/network-map.md" >}}). -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -170,7 +170,7 @@ Read more in [Ledger]({{< relref "../../key-concepts-ledger.md" >}}). ### Attachments Read more in [Working with attachments]({{< relref "../../get-started/tutorials/supplementary-tutorials/tutorial-attachments.md" >}}) and [Node services]({{< relref "../../node-services.md" >}}). -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -466,7 +466,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -495,7 +495,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/platform/corda/4.8/enterprise/node/pki-guide.md b/content/en/platform/corda/4.8/enterprise/node/pki-guide.md index 826abb47ceb..140c4990e3c 100644 --- a/content/en/platform/corda/4.8/enterprise/node/pki-guide.md +++ b/content/en/platform/corda/4.8/enterprise/node/pki-guide.md @@ -54,7 +54,7 @@ as they root to the same certificate. Other than that, Corda nodes stay agnostic to the certificate hierarchy (in particular the depth of the certificate hierarchy tree). -{{< figure alt="hierarchy agnostic" width=80% zoom="../resources/hierarchy-agnostic.png" >}} +{{< figure alt="hierarchy agnostic" width=80% src="../resources/hierarchy-agnostic.png" >}} At the time of writing this document, the Corda Network assumes the certificate hierarchy that can be found in the [Certificate hierarchy guide]({{< relref "../network/permissioning.md#certificate-hierarchy" >}}). @@ -69,7 +69,7 @@ The network operator is responsible for certificate issuance and maintenance for at the Identity Manager and Network Map certificates. The rest of the certificate chain (i.e. every certificate below the Identity Manager certificate) falls into node operator responsibility. -{{< figure alt="tls hierarchy" width=80% zoom="../resources/tls-hierarchy.png" >}} +{{< figure alt="tls hierarchy" width=80% src="../resources/tls-hierarchy.png" >}} The certificate revocation list verification applies to the entire chain. This means that every certificate in the chain is going to be validated against the corresponding certificate revocation list during the SSL handshake. Consequently, this means that a node operator is expected to provide and maintain the certificate revocation list for the Node CA. @@ -87,7 +87,7 @@ During the certificate revocation list validation process the trust store is con As an example, let us consider the following certificate hierarchy: -{{< figure alt="example hierarchy" width=80% zoom="../resources/example-hierarchy.png" >}} +{{< figure alt="example hierarchy" width=80% src="../resources/example-hierarchy.png" >}} The certificate hierarchy presented above is currently (as of the time of writing this document) used in the Corda Network. It follows practices applicable for certificate authorities providing a balance between security and simplicity of usage. In this scenario, a network operator wants to create a CA hierarchy where the self-signed Root CA issues a certificate for the Subordinate CA which in turn issues diff --git a/content/en/platform/corda/4.8/enterprise/notary-healthcheck.md b/content/en/platform/corda/4.8/enterprise/notary-healthcheck.md index 43010f7a0cb..d45632ba2b8 100644 --- a/content/en/platform/corda/4.8/enterprise/notary-healthcheck.md +++ b/content/en/platform/corda/4.8/enterprise/notary-healthcheck.md @@ -171,4 +171,4 @@ monitor notary health via a dashboard or hook up an alerter. As an example, this view on a failing notary check. Note the metrics for *success*, *fail*, *inflight*, and *maxinflightTime* for the notary service and the cluster members on the left hand side. -{{< figure alt="hawtio healthcheck" width=80% zoom="./resources/hawtio-healthcheck.png" >}} +{{< figure alt="hawtio healthcheck" width=80% src="./resources/hawtio-healthcheck.png" >}} diff --git a/content/en/platform/corda/4.8/enterprise/notary/backup-restore.md b/content/en/platform/corda/4.8/enterprise/notary/backup-restore.md index 4f23ba8566b..907fa2a7549 100644 --- a/content/en/platform/corda/4.8/enterprise/notary/backup-restore.md +++ b/content/en/platform/corda/4.8/enterprise/notary/backup-restore.md @@ -29,7 +29,7 @@ Additionally, it is critical to have a backup of the Notary Service identity pri The following diagram highlights in blue which storage components should be backed up. -{{< figure alt="storage components" width=80% zoom="../resources/storage-components.png" >}} +{{< figure alt="storage components" width=80% src="../resources/storage-components.png" >}} Note that for regular nodes it is very important to back up the Messaging Broker (Artemis) folder and the local Database, but for HA notary nodes that are purely used for notarisation purposes that is not needed. To summarise: diff --git a/content/en/platform/corda/4.8/enterprise/notary/ha-notary-service-overview.md b/content/en/platform/corda/4.8/enterprise/notary/ha-notary-service-overview.md index 04d0c2c1e1c..ba7d24ec275 100644 --- a/content/en/platform/corda/4.8/enterprise/notary/ha-notary-service-overview.md +++ b/content/en/platform/corda/4.8/enterprise/notary/ha-notary-service-overview.md @@ -60,7 +60,7 @@ database to store its node state (e.g. its identity information). We can visualise this set-up as follows, with the regular Corda nodes in green, the Corda notary worker nodes in red, and the standard node databases and notary state database replicas in blue. -{{< figure alt="ha notary overview2" width=80% zoom="../resources/ha-notary-overview2.png" >}} +{{< figure alt="ha notary overview2" width=80% src="../resources/ha-notary-overview2.png" >}} Nodes requesting notarisation from a highly-available notary will connect to the notary workers in round-robin fashion. Provided there are multiple notary workers and the notary state database is configured to be highly-available, the overall notary service @@ -73,7 +73,7 @@ In production, R3 recommends running five or more replicas in the notary state d If desired, you can choose to run each database server and its Corda notary worker on the same machine: -{{< figure alt="ha notary colocated" width=80% zoom="../resources/ha-notary-colocated.png" >}} +{{< figure alt="ha notary colocated" width=80% src="../resources/ha-notary-colocated.png" >}} ## Notary configuration diff --git a/content/en/platform/corda/4.8/enterprise/notary/hsm-support.md b/content/en/platform/corda/4.8/enterprise/notary/hsm-support.md index fda06921fbe..bc481a66d29 100644 --- a/content/en/platform/corda/4.8/enterprise/notary/hsm-support.md +++ b/content/en/platform/corda/4.8/enterprise/notary/hsm-support.md @@ -14,7 +14,7 @@ weight: 3 ## Overview -{{< figure alt="hsm support" width=80% zoom="../resources/hsm-support.png" >}} +{{< figure alt="hsm support" width=80% src="../resources/hsm-support.png" >}} Two notary workers and their relevant cryptographic keys used for P2P messaging and transaction signing. The red rectangles represent the Corda notary worker services. The distinct identity keys are represented by rectangles in green and yellow and the shared key of the notary service identity is drawn in blue. Their cryptographic keys are held in a single HSM. diff --git a/content/en/platform/corda/4.8/enterprise/operations/deployment/firewall-deployment.md b/content/en/platform/corda/4.8/enterprise/operations/deployment/firewall-deployment.md index 16f2e534f73..4a74f132586 100644 --- a/content/en/platform/corda/4.8/enterprise/operations/deployment/firewall-deployment.md +++ b/content/en/platform/corda/4.8/enterprise/operations/deployment/firewall-deployment.md @@ -130,14 +130,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -150,7 +150,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/platform/corda/4.8/enterprise/performance-testing/introduction.md b/content/en/platform/corda/4.8/enterprise/performance-testing/introduction.md index dda75e2b673..3f1422984dc 100644 --- a/content/en/platform/corda/4.8/enterprise/performance-testing/introduction.md +++ b/content/en/platform/corda/4.8/enterprise/performance-testing/introduction.md @@ -110,7 +110,7 @@ The driving app sits outside the network and connects to the JMeter servers thro measuring the throughput of a node, the test definition instructs all JMeter servers to open RPC connections to one node, thus saturating the RPC handler and driving the node as hard as possible. The test might invoke a flow that can be completed locally (for example, cash issuance) or it might require exchanging P2P messages with other nodes (for example, cash payment). -{{< figure alt="jmeter network overview" width=80% zoom="../resources/jmeter-network-overview.png" >}} +{{< figure alt="jmeter network overview" width=80% src="../resources/jmeter-network-overview.png" >}} ## Performance tests diff --git a/content/en/platform/corda/4.8/enterprise/performance-testing/jmeter-samplers.md b/content/en/platform/corda/4.8/enterprise/performance-testing/jmeter-samplers.md index 7a63ae4e3b3..5e939d42f1e 100644 --- a/content/en/platform/corda/4.8/enterprise/performance-testing/jmeter-samplers.md +++ b/content/en/platform/corda/4.8/enterprise/performance-testing/jmeter-samplers.md @@ -66,7 +66,7 @@ server, not the client machine. * `minimumNodePlatformVersion`: the minimum platform version that the JMeter client will require from the Corda nodes. It defaults to 4, which can be used to test with Corda 4.0 nodes or later. * `username`: the RPC user name of the Corda node. * `password`: the RPC password of the Corda node. -{{< figure alt="empty flow sampler" width=80% zoom="../resources/empty-flow-sampler.png" >}} +{{< figure alt="empty flow sampler" width=80% src="../resources/empty-flow-sampler.png" >}} * `CashIssueSampler`: this sampler client has the class name `com.r3.corda.jmeter.CashIssueSampler` and starts the flow `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueFlow`. This flow self-issues 1.1 billion cash tokens on the node it is running on, and stores it in the vault. In addition to the common properties described for `EmptyFlowSampler` above, this sampler client also requires: * `notaryName`: the X500 name of the notary that is acceptable to transfer cash tokens issued via this sampler. Issuing tokens does not need to be notarised, and therefore invoking this sampler does not create traffic to the notary. However, the notary is stored as part of the cash state and must be valid to do anything else with the cash state, therefore this sampler checks the notary identity against the network parameters of the node. * `CashIssueAndPaySampler`: this sampler client has the classname `com.r3.corda.jmeter.CashIssueAndPaySampler` and, depending on its parameters, it can start either of these flows - `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndPaymentFlow` or `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndpaymentNoSelection`. Either way it issues 2 million dollars in tokens and then transfers the sum to a configurable other node, thus invoking the full vault access, peer-to-peer communication and notarisation cycle. In addition to the parameters required for `CashIssueSampler`, this sampler also requires: diff --git a/content/en/platform/corda/4.8/enterprise/performance-testing/jmeter-testplans.md b/content/en/platform/corda/4.8/enterprise/performance-testing/jmeter-testplans.md index a731939adf3..7a86735bed0 100644 --- a/content/en/platform/corda/4.8/enterprise/performance-testing/jmeter-testplans.md +++ b/content/en/platform/corda/4.8/enterprise/performance-testing/jmeter-testplans.md @@ -25,12 +25,12 @@ The testplan is a hierarchy of configuration elements. The only elements used in *Variables*, *Thread Groups*, *Samplers* and *Listeners*. Rather than creating a new testplan from scratch, it might a good idea to take a copy of one of the provided example test plans and modify that. -{{< figure alt="jmeter testplan" width=80% zoom="../resources/jmeter-testplan.png" >}} +{{< figure alt="jmeter testplan" width=80% src="../resources/jmeter-testplan.png" >}} A variables element defines key/value pairs that can be used in all following following elements instead of string literals. They can be referenced by using a `$` sign and curly braces, e.g. `${varName}`. -{{< figure alt="variables" width=80% zoom="../resources/variables.png" >}} +{{< figure alt="variables" width=80% src="../resources/variables.png" >}} A thread group collects a set of actions that form one step in the test plan. All elements within a thread group diff --git a/content/en/platform/corda/4.8/enterprise/performance-testing/performance-results.md b/content/en/platform/corda/4.8/enterprise/performance-testing/performance-results.md index 0cd307f4688..d6f17969511 100644 --- a/content/en/platform/corda/4.8/enterprise/performance-testing/performance-results.md +++ b/content/en/platform/corda/4.8/enterprise/performance-testing/performance-results.md @@ -40,7 +40,7 @@ the time of Corda Enterprise Edition 4 release). This is with each node running running **Microsoft SQL Server**. Similar results were obtained against the other supported databases. -{{< figure alt="ce4 comparison chart" width=80% zoom="/en/images/ce4-comparison-chart.png" >}} +{{< figure alt="ce4 comparison chart" width=80% src="/en/images/ce4-comparison-chart.png" >}} Figure 1 @@ -52,7 +52,7 @@ varies with the number of those payments combined together. This can be useful be a technique for even greater throughput. -{{< figure alt="states per second" width=80% zoom="/en/images/states-per-second.png" >}} +{{< figure alt="states per second" width=80% src="/en/images/states-per-second.png" >}} Figure 2 @@ -65,7 +65,7 @@ of Figure 3 were achieved using Corda Enterprise 3.0 on **Microsoft Azure** virt with minimal latency between the node VM and the database server VM. -{{< figure alt="comparison chart" width=80% zoom="/en/images/comparison-chart.png" >}} +{{< figure alt="comparison chart" width=80% src="/en/images/comparison-chart.png" >}} Figure 3 @@ -303,7 +303,7 @@ All these machines were 24 core (48 hyper-threads), based on 2x Intel Xeon E5-26 The first test performed was focused on the latency aspect. Load was generated from a single client initialised in a machine that was separate from the ones hosting the Corda nodes and their databases. The load consisted of a pre-defined number of flows (400) that were executed one after the other sequentially. Each one of those flows was initiated on the central exchange node, which was responsible for collecting signatures from all the parties involved and for finalising the transaction. Each of those flows performed a swap of two states between every pair of nodes, thus leading to a Corda transaction with 10 input and 10 output states. During the test setup, the necessary amount of states was initially issued and each one of those states would be swapped once during the test. In order to also measure the impact of transaction resolution, during the test setup each of these states was transferred bilaterally between the nodes in each pair ten times, thus generating a backchain of depth 10. This meant that during every Corda transaction, each node would have to resolve the backchain of the states belonging to the other pairs - so each node would have to resolve 80 states (8 nodes x 10 states each). In order to also measure the scaling with regard to the number of nodes, the exact same test was repeated with a varying number of participants, starting from 4 nodes and going up to 10. The test was also repeated three times with Corda Enterprise versions 4.3, 4.4, and 4.5. The goal was to isolate the benefits from bulk transaction resolution, introduced in version 4.4, and parallelised flows (`CollectSignaturesFlow` / `FinalityFlow`), introduced in version 4.5. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average latency of the flow that performed the asset swap in milliseconds. -{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.3 shows an exponential increase in the latency of the flow as the number of nodes that participate in the transaction is increased. This can be attributed to the following two reasons. Firstly, during the tests the exchange node was performing the `CollectSignaturesFlow` and `FinalityFlow` flows sequentially across the involved nodes, so the more nodes these flows had to iterate over, the more time it took. Secondly, these flows have the capability to trigger the execution of transaction resolution if they identify states for which the node is missing the provenance chain. In Corda Enterprise Edition 4.3, transaction resolution is not performed in bulk - it is performed one state at a time. As a result, every additional node causes a significant amount of extra work to be done. @@ -314,7 +314,7 @@ The main observations from the tests follow below: The second test was focused on the throughput aspect. Load was generated from multiple clients initialised on the machines that were hosting the Corda nodes, which were acting as JMeter servers orchestrated by a JMeter client running on a separate machine. The goal was to saturate the participating Corda nodes and to prevent the single client from becoming the bottleneck. During the test setup, each client issued one state to every node. Each client was then performing one flow at a time, swapping these states between the participating nodes. No backchain was generated as part of this test. As a result, the test was executed only between Corda Enterprise Edition 4.3 and Corda Enterprise Edition 4.5, and with a varying number of nodes ranging from 2 up to 10. Each of the machines driving the load was using 120 concurrent clients, which summed up to 480 concurrent clients in total. Additional measurements were performed with a varying number of clients, in order to ensure that this was the optimal number of clients to saturate the nodes without overloading them. Since the throughput was different depending on the number of participating nodes, the total number of requests was also adjusted accordingly in order to get roughly the same total duration of approximately 20 minutes. In all the scenarios, it was confirmed that the nodes had reached a stable state when the test ended. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average throughput measured in the number of flows completed per second. -{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.5 can achieve a significantly higher throughput when compared to Corda Enterprise Edition 4.3. This can be attributed to the following factors: @@ -336,9 +336,9 @@ Five different variations were tested, as follows: The purpose of this last test was to investigate the effects of these options in both throughput and latency because some of these options introduce trade-offs between these two aspects. To this end, the tests described earlier in this analysis were repeated using the variations listed above. For the latency measurements, 10 nodes were used because, thanks to the low load, there was no expectation for any big interference between nodes on the same machine. For the throughput measurements, only 4 nodes were used in order to avoid any interference between nodes on the same machine due to the high load. The results are shown in the diagrams below - the *x* axis contains the variations used, and the *y* axis shows the average throughput and latency achieved with each variation along with error bars indicating the standard deviation. -{{< figure alt="CE 4.5 variants latency comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_latency.png" >}} +{{< figure alt="CE 4.5 variants latency comparison chart" width=80% src="../resources/performance-testing/4-5_variants_latency.png" >}} -{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_throughput.png" >}} +{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% src="../resources/performance-testing/4-5_variants_throughput.png" >}} The main observations from the test are as follows: * Disabling compression leads to lower throughput and higher latency. This is expected because compression introduces a trade-off between CPU and network bandwidth utilisation and in most cases the network would prove to be a bigger bottleneck. diff --git a/content/en/platform/corda/4.8/enterprise/performance-testing/practical-considerations.md b/content/en/platform/corda/4.8/enterprise/performance-testing/practical-considerations.md index 8fa0c8bdf6d..b626738a2f3 100644 --- a/content/en/platform/corda/4.8/enterprise/performance-testing/practical-considerations.md +++ b/content/en/platform/corda/4.8/enterprise/performance-testing/practical-considerations.md @@ -94,7 +94,7 @@ To collect the output of a JMeter performance run, we need to add listeners to t This listener just lists all the runs that have been completed, one run per row, stating the thread name, sampler label, the sample time in milliseconds, the result status and the latency in milliseconds, among other (usually less useful) fields. -{{< figure alt="jmeter results table" width=80% zoom="../resources/jmeter-results-table.png" >}} +{{< figure alt="jmeter results table" width=80% src="../resources/jmeter-results-table.png" >}} This view is particularly useful when trying out any changes (new flow, new sampler, new installation) to see if it is working at all. The potential outcomes are: @@ -123,7 +123,7 @@ This listener aggregates all the runs for each thread group and the whole test p It also allows plotting these statistics in basic charts and to save the results as a csv file. This is what we use for looking at the performance results on a day to day basis. -{{< figure alt="jmeter results aggregate" width=80% zoom="../resources/jmeter-results-aggregate.png" >}} +{{< figure alt="jmeter results aggregate" width=80% src="../resources/jmeter-results-aggregate.png" >}} This listener has one line for each sampler being run as part of the test plan, and a total line summing up/averaging the results for the whole test plan. diff --git a/content/en/platform/corda/4.8/enterprise/performance-testing/r3-performance-runs.md b/content/en/platform/corda/4.8/enterprise/performance-testing/r3-performance-runs.md index a61b21bc434..e88930d8cf2 100644 --- a/content/en/platform/corda/4.8/enterprise/performance-testing/r3-performance-runs.md +++ b/content/en/platform/corda/4.8/enterprise/performance-testing/r3-performance-runs.md @@ -32,7 +32,7 @@ The performance network sits behind a firewall that allows incoming connections within the network can connect to each other on a range of ports (Corda Remote Procedure Call (RPC), Corda peer to peer connection (P2P) and JDBC connections to various database servers are all allowed). -{{< figure alt="performance cluster" width=80% zoom="../resources/performance-cluster.png" >}} +{{< figure alt="performance cluster" width=80% src="../resources/performance-cluster.png" >}} A Corda JMeter server instance is running on all 4 nodes and on the notary server. The JMeter client connects to the JMeter server instances via SSH tunnels. As the JMeter servers run within the firewalled network, they are free to diff --git a/content/en/platform/corda/4.8/enterprise/performance-testing/running-jmeter-corda.md b/content/en/platform/corda/4.8/enterprise/performance-testing/running-jmeter-corda.md index 360565c7e72..72708f1fbed 100644 --- a/content/en/platform/corda/4.8/enterprise/performance-testing/running-jmeter-corda.md +++ b/content/en/platform/corda/4.8/enterprise/performance-testing/running-jmeter-corda.md @@ -54,7 +54,7 @@ interactively either locally or remotely, and view results. The UI has a set of quickly create or load a testplan, control local or remote test runs, and clear any test results collected so far. The latter is particularly important when looking at averages, as old data might skew the results being looked at. -{{< figure alt="jmeter buttons" width=80% zoom="../resources/jmeter-buttons.png" >}} +{{< figure alt="jmeter buttons" width=80% src="../resources/jmeter-buttons.png" >}} The *clear current view* button only clears the data in the currently viewed output collector - if a test plan has several output listeners defined (as in the example above, we have *Aggregate Graph*, *Graph Results* and *View Results in Table*), any collector not currently selected is not affected. *Clear all data* will clear the results from all collectors. diff --git a/content/en/platform/corda/4.9/enterprise/api-core-types.md b/content/en/platform/corda/4.9/enterprise/api-core-types.md index 6b7c6004c35..015d1286b60 100644 --- a/content/en/platform/corda/4.9/enterprise/api-core-types.md +++ b/content/en/platform/corda/4.9/enterprise/api-core-types.md @@ -66,11 +66,11 @@ signatures it requires. An illustration of an *“either Alice and Bob, or Charlie”* composite key: -{{< figure alt="composite key" width=80% zoom="./resources/composite-key.png" >}} +{{< figure alt="composite key" width=80% src="./resources/composite-key.png" >}} To allow further flexibility, each child node can have an associated custom *weight* (the default is 1). The *threshold* then specifies the minimum total weight of all children required. Our previous example can also be expressed as: -{{< figure alt="composite key 2" width=80% zoom="./resources/composite-key-2.png" >}} +{{< figure alt="composite key 2" width=80% src="./resources/composite-key-2.png" >}} Signature verification is performed in two stages: diff --git a/content/en/platform/corda/4.9/enterprise/apps/bankinabox/user-interface/how-to.md b/content/en/platform/corda/4.9/enterprise/apps/bankinabox/user-interface/how-to.md index 931d84abfa4..a5ef0860dd6 100644 --- a/content/en/platform/corda/4.9/enterprise/apps/bankinabox/user-interface/how-to.md +++ b/content/en/platform/corda/4.9/enterprise/apps/bankinabox/user-interface/how-to.md @@ -70,7 +70,7 @@ Follow these steps to create a new customer profile. When the customer profile is created, they will not have any accounts - you will have to create them. Learn how under [Creating accounts](#create-a-current-account). {{< /note >}} -{{< figure alt="Create customer profile" width=80% zoom="/en/gifs/create-customer-biab-1.0.gif" >}} +{{< figure alt="Create customer profile" width=80% src="/en/gifs/create-customer-biab-1.0.gif" >}} ### Create a Current account @@ -94,7 +94,7 @@ When the customer profile is created, they will not have any accounts - you will 7. When an account is created, it is in **PENDING** status. This must be changed to **ACTIVE** for a customer to be able to interact with and use the account. See [Change an account status](#change-an-account-status) for more information. -{{< figure alt="Create account" width=80% zoom="/en/gifs/create-current-account-biab-1.0.gif" >}} +{{< figure alt="Create account" width=80% src="/en/gifs/create-current-account-biab-1.0.gif" >}} ### Create a Savings account @@ -140,7 +140,7 @@ An account has three statuses: **PENDING**, **ACTIVE**, and **SUSPENDED**. When If the account needs to be suspended, follow the same steps but select **SUSPENDED**. -{{< figure alt="Set account status" width=80% zoom="/en/gifs/set-account-status-biab-1.0.gif" >}} +{{< figure alt="Set account status" width=80% src="/en/gifs/set-account-status-biab-1.0.gif" >}} ### Assign or revoke a user role @@ -163,7 +163,7 @@ To assign a user role, follow these steps: 5. Click **Revoke**. A message will appear indicating that the user role was assigned successfully. -{{< figure alt="Assign role" width=80% zoom="/en/gifs/assign-a-role-biab-1.0.gif" >}} +{{< figure alt="Assign role" width=80% src="/en/gifs/assign-a-role-biab-1.0.gif" >}} #### Revoke a user role @@ -179,7 +179,7 @@ To revoke a user role, follow these steps: 5. Click **Save**. A message will appear indicating that the user role was revoked successfully. -{{< figure alt="Revoke role" width=80% zoom="/en/gifs/revoke-role-biab-1.0.gif" >}} +{{< figure alt="Revoke role" width=80% src="/en/gifs/revoke-role-biab-1.0.gif" >}} ### Issue a loan @@ -195,7 +195,7 @@ Once the account has been set to **ACTIVE**, you will have the ability to issue A loan account is created when a loan has been issued successfully. -{{< figure alt="Issue loan" width=80% zoom="/en/gifs/issue-loan-biab-1.0.gif" >}} +{{< figure alt="Issue loan" width=80% src="/en/gifs/issue-loan-biab-1.0.gif" >}} ### Approve overdrafts @@ -215,7 +215,7 @@ To approve an overdraft, follow these steps. Overdrafts can be approved whether the account is **PENDING**, **ACTIVE**, or **SUSPENDED**. {{< /note >}} -{{< figure alt="Approve overdraft" width=80% zoom="/en/gifs/approve-overdraft-biab-1.0.gif" >}} +{{< figure alt="Approve overdraft" width=80% src="/en/gifs/approve-overdraft-biab-1.0.gif" >}} ### Deposit money to an account @@ -230,7 +230,7 @@ Follow these steps to deposit money to a customer account. 4. Click **Save**. You will receive a message indicating that the deposit was successful. -{{< figure alt="Deposit" width=80% zoom="/en/gifs/deposit-biab-1.0.gif" >}} +{{< figure alt="Deposit" width=80% src="/en/gifs/deposit-biab-1.0.gif" >}} ### Register as a user on Bank in a Box @@ -251,7 +251,7 @@ You must be registered as a **Customer** or **Admin** on Bank in a Box to perfor 5. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update customer profile @@ -284,7 +284,7 @@ An **Admin user** can set an account's **Withdrawal daily limit** or **Transfer 2. Click **Save** when you have entered the desired limits. A message will appear indicating that the limits have been saved successfully. -{{< figure alt="Set withdrawal and transfer limits - admin" width=80% zoom="/en/gifs/set-limits-admin-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - admin" width=80% src="/en/gifs/set-limits-admin-biab-1.0.gif" >}} ## Customer tasks @@ -309,12 +309,12 @@ Follow these steps to create a new intrabank payment. 6. Click **Save**. You will receive a notification indicating that the payment was created successfully. You will also receive notifications indicating any changes in your account balances. -{{< figure alt="Create intrabank payment" width=80% zoom="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} +{{< figure alt="Create intrabank payment" width=80% src="/en/gifs/create-intrabank-payment-biab-1.0.gif" >}} After making a payment, you can view the details of this transaction on the Transactions screen. -{{< figure alt="View transaction" width="800" width=80% zoom="/en/gifs/view-transaction-biab-1.0.gif" >}} +{{< figure alt="View transaction" width="800" width=80% src="/en/gifs/view-transaction-biab-1.0.gif" >}} ### Create a recurring payment @@ -338,7 +338,7 @@ Follow these steps to create a recurring payment: 3. You will be taken back to the **Recurring payments screen** where you will receive a message indicating that the recurring payment was created successfully. -{{< figure alt="Recurring payment" width=80% zoom="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} +{{< figure alt="Recurring payment" width=80% src="/en/gifs/create-recurring-payment-biab-1.0.gif" >}} {{< note >}} This payment will not appear on the **Recurring payments screen** until the first iteration has occurred. @@ -367,7 +367,7 @@ You must be registered as a Customer or Admin on Bank in a Box to perform tasks. 7. Click **Save**. A message will appear indicating that you have registered successfully. -{{< figure alt="Register user" width=80% zoom="/en/gifs/register-user-customer-biab-1.0.gif" >}} +{{< figure alt="Register user" width=80% src="/en/gifs/register-user-customer-biab-1.0.gif" >}} ### Update a customer profile @@ -406,4 +406,4 @@ To set these limits as a **Customer**, follow these steps. 4. Click **Save**. You will be taken back to the Account page where you will receive a message indicating that the limits have been updated successfully. -{{< figure alt="Set withdrawal and transfer limits - customer" width=80% zoom="/en/gifs/set-limits-customer-biab-1.0.gif" >}} +{{< figure alt="Set withdrawal and transfer limits - customer" width=80% src="/en/gifs/set-limits-customer-biab-1.0.gif" >}} diff --git a/content/en/platform/corda/4.9/enterprise/contract-irs.md b/content/en/platform/corda/4.9/enterprise/contract-irs.md index 0c5f0ddb288..63d5fac513b 100644 --- a/content/en/platform/corda/4.9/enterprise/contract-irs.md +++ b/content/en/platform/corda/4.9/enterprise/contract-irs.md @@ -45,7 +45,7 @@ the view of the floating leg receiver / fixed leg payer. The enumerated document it progresses (note that, the first version exists before the value date), the dots on the “y=0” represent an interest rate value becoming available and then the curved arrow indicates to which period the fixing applies. -{{< figure alt="contract irs" width=80% zoom="./resources/contract-irs.png" >}} +{{< figure alt="contract irs" width=80% src="./resources/contract-irs.png" >}} Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period, there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360. diff --git a/content/en/platform/corda/4.9/enterprise/cordapp-advanced-concepts.md b/content/en/platform/corda/4.9/enterprise/cordapp-advanced-concepts.md index 6b546e4e36f..d12112a505d 100644 --- a/content/en/platform/corda/4.9/enterprise/cordapp-advanced-concepts.md +++ b/content/en/platform/corda/4.9/enterprise/cordapp-advanced-concepts.md @@ -71,7 +71,7 @@ all objects are loaded in the same classloader and can be freely used and filter Behind the scenes, the matter is more complex. As can be seen in this illustration: -{{< figure alt="tx chain" width=80% zoom="./resources/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="./resources/tx-chain.png" >}} {{< note >}} Corda’s design is based on the UTXO model. In a serialized transaction the input and reference states are *StateRefs* - only references diff --git a/content/en/platform/corda/4.9/enterprise/cordapps/api-flows.md b/content/en/platform/corda/4.9/enterprise/cordapps/api-flows.md index ddff0766d09..3d3c251261c 100644 --- a/content/en/platform/corda/4.9/enterprise/cordapps/api-flows.md +++ b/content/en/platform/corda/4.9/enterprise/cordapps/api-flows.md @@ -91,7 +91,7 @@ The `initiator`: You can visualize the work performed by initiator like this: -{{< figure alt="flow overview" width=80% zoom="../resources/flow-overview.png" >}} +{{< figure alt="flow overview" width=80% src="../resources/flow-overview.png" >}} ## Responder flow class example diff --git a/content/en/platform/corda/4.9/enterprise/cordapps/api-states.md b/content/en/platform/corda/4.9/enterprise/cordapps/api-states.md index 50f46532f5a..e518a9fab63 100644 --- a/content/en/platform/corda/4.9/enterprise/cordapps/api-states.md +++ b/content/en/platform/corda/4.9/enterprise/cordapps/api-states.md @@ -62,7 +62,7 @@ states evolve in a straight line by superseding themselves. You can visualize the hierarchy like this: -{{< figure alt="state hierarchy" width=80% zoom="/en/images/state-hierarchy.png" >}} +{{< figure alt="state hierarchy" width=80% src="/en/images/state-hierarchy.png" >}} ### LinearState diff --git a/content/en/platform/corda/4.9/enterprise/cordapps/cordapp-overview.md b/content/en/platform/corda/4.9/enterprise/cordapps/cordapp-overview.md index 1a8c0e9d89f..51c81b33975 100644 --- a/content/en/platform/corda/4.9/enterprise/cordapps/cordapp-overview.md +++ b/content/en/platform/corda/4.9/enterprise/cordapps/cordapp-overview.md @@ -31,7 +31,7 @@ CorDapps are: A Corda Distributed Application (CorDapp) solves a specific problem using the Corda framework. CorDapps are stored on Corda nodes and executed on the Corda network. This *distributes* the app, allowing it to run on multiple systems simultaneously—unlike traditional apps, which utilize one dedicated system to achieve an assigned task. CorDapps let nodes communicate with each other to reach agreement on updates to the ledger by defining flows that Corda node owners can invoke over RPC: -{{< figure alt="node diagram" width=80% zoom="../resources/node-diagram.png" >}} +{{< figure alt="node diagram" width=80% src="../resources/node-diagram.png" >}} ## Glossary diff --git a/content/en/platform/corda/4.9/enterprise/cordapps/deterministic-jvm.md b/content/en/platform/corda/4.9/enterprise/cordapps/deterministic-jvm.md index 46a0841d530..d1039688002 100644 --- a/content/en/platform/corda/4.9/enterprise/cordapps/deterministic-jvm.md +++ b/content/en/platform/corda/4.9/enterprise/cordapps/deterministic-jvm.md @@ -75,7 +75,7 @@ severity `ERROR` will prevent execution. The sandbox has a configuration that applies to the execution of a specific runnable. This configuration, on a higher level, contains a set of rules, definition providers and emitters. -{{< figure alt="djvm overview" width=80% zoom="../resources/djvm-overview.png" >}} +{{< figure alt="djvm overview" width=80% src="../resources/djvm-overview.png" >}} The set of rules is what defines the constraints posed on the runtime environment. A rule can act on three different levels, namely on a type-, member- or instruction-level. The set of rules get processed and validated by the `RuleValidator` prior to execution. diff --git a/content/en/platform/corda/4.9/enterprise/cordapps/upgrading-cordapps.md b/content/en/platform/corda/4.9/enterprise/cordapps/upgrading-cordapps.md index 4b9bec22684..c1e188704ec 100644 --- a/content/en/platform/corda/4.9/enterprise/cordapps/upgrading-cordapps.md +++ b/content/en/platform/corda/4.9/enterprise/cordapps/upgrading-cordapps.md @@ -68,7 +68,7 @@ change is one that changes the interface of the flow. The flow interface is defined by the sequence of `send` and `receive` calls between an `InitiatingFlow` and an `InitiatedBy` flow, including the types of the data sent and received. We can picture a flow’s interface as follows: -{{< figure alt="flow interface" width=80% zoom="../resources/flow-interface.png" >}} +{{< figure alt="flow interface" width=80% src="../resources/flow-interface.png" >}} In the diagram above, the `InitiatingFlow`: diff --git a/content/en/platform/corda/4.9/enterprise/financial-model.md b/content/en/platform/corda/4.9/enterprise/financial-model.md index 57d7427d1ef..d2c97f938de 100644 --- a/content/en/platform/corda/4.9/enterprise/financial-model.md +++ b/content/en/platform/corda/4.9/enterprise/financial-model.md @@ -92,6 +92,6 @@ countable (in cents), barrels of oil are fungible and countable (oil from two sm container), shares of the same class in a specific company are fungible and countable, and so on. This diagram illustrates the complete contract state hierarchy: -{{< figure alt="financialContractStateModel" width=80% zoom="/en/images/financialContractStateModel.png" >}} +{{< figure alt="financialContractStateModel" width=80% src="/en/images/financialContractStateModel.png" >}} Corda provides two packages: a core library and a finance model-specific library. You can re-use or extend the finance types directly, or write your own by extending the base types from the core library. diff --git a/content/en/platform/corda/4.9/enterprise/health-survey.md b/content/en/platform/corda/4.9/enterprise/health-survey.md index 6e0a0e0f348..5b0ff874fe6 100644 --- a/content/en/platform/corda/4.9/enterprise/health-survey.md +++ b/content/en/platform/corda/4.9/enterprise/health-survey.md @@ -116,7 +116,7 @@ The Corda Health Survey currently does not support testing RPC communication if The tool generates the archive of the collected files in the same directory it is ran in. The names are in the format: `report-date-time.zip` -{{< figure alt="health survey photo" width=80% zoom="resources/health-survey-photo.png" >}} +{{< figure alt="health survey photo" width=80% src="resources/health-survey-photo.png" >}} ## Deployment health check diff --git a/content/en/platform/corda/4.9/enterprise/key-concepts-consensus.md b/content/en/platform/corda/4.9/enterprise/key-concepts-consensus.md index 0c1984a376d..90733e52647 100644 --- a/content/en/platform/corda/4.9/enterprise/key-concepts-consensus.md +++ b/content/en/platform/corda/4.9/enterprise/key-concepts-consensus.md @@ -49,7 +49,7 @@ transferring a treasury bond, the bond transfer is only valid if: Walking the chain for this transaction would look like this: -{{< figure alt="validation consensus" width=80% zoom="/en/images/validation-consensus.png" >}} +{{< figure alt="validation consensus" width=80% src="/en/images/validation-consensus.png" >}} When verifying a proposed transaction, a node may not have every transaction in the transaction chain that they need to verify. In this case, they can request the missing transactions from the transaction proposer. The @@ -68,7 +68,7 @@ proposals: Both transactions will achieve validity consensus, yet Alice has managed to “double-spend” her USD to get double the amount of GBP and EUR: -{{< figure alt="uniqueness consensus" width=80% zoom="/en/images/uniqueness-consensus.png" >}} +{{< figure alt="uniqueness consensus" width=80% src="/en/images/uniqueness-consensus.png" >}} To prevent this, a valid transaction proposal must also achieve uniqueness consensus. Uniqueness consensus is the requirement that none of the inputs to a proposed transaction have already been consumed in another transaction. diff --git a/content/en/platform/corda/4.9/enterprise/key-concepts-contracts.md b/content/en/platform/corda/4.9/enterprise/key-concepts-contracts.md index 5bf93b1f6ff..6774d6dcdf8 100644 --- a/content/en/platform/corda/4.9/enterprise/key-concepts-contracts.md +++ b/content/en/platform/corda/4.9/enterprise/key-concepts-contracts.md @@ -55,7 +55,7 @@ transaction gathers all the required signatures, it can't be executed unless it Each transaction [state]({{< relref "key-concepts-states.md" >}}) specifies a *contract type*. The contract specified takes the transaction as input, and determines if the transaction is valid based on the contract's internal rules. The contract must evaluate every input state and every output state. -{{< figure alt="tx validation" width=80% zoom="/en/images/tx-validation.png" >}} +{{< figure alt="tx validation" width=80% src="/en/images/tx-validation.png" >}} The contract code can: * Check the number of inputs, outputs, commands, or attachments. diff --git a/content/en/platform/corda/4.9/enterprise/key-concepts-ecosystem.md b/content/en/platform/corda/4.9/enterprise/key-concepts-ecosystem.md index 6894626c5ce..dab2e9b0517 100644 --- a/content/en/platform/corda/4.9/enterprise/key-concepts-ecosystem.md +++ b/content/en/platform/corda/4.9/enterprise/key-concepts-ecosystem.md @@ -32,7 +32,7 @@ title: Networks, identity, and discovery ## What is a network? On Corda, people and business interact by communicating over a peer-to-peer network of [Corda nodes]({{< relref "key-concepts-node.md" >}}). Each node represents a legal entity running Corda and one or more Corda distributed applications, known as [CorDapps]({{< relref "cordapps/cordapp-overview.md" >}}). -{{< figure alt="network" width=80% zoom="/en/images/network.png" >}} +{{< figure alt="network" width=80% src="/en/images/network.png" >}} Corda is different from other distributed ledgers because all communication between nodes is point-to-point, and only shared on a need-to-know basis. It is also encrypted using transport-layer security. There are *no global broadcasts* to all parties on a network, but all of the nodes in a network can send messages directly to other nodes. If the recipient is offline, the message waits in an outbound queue until they are online again—just like an email. ## Join a network diff --git a/content/en/platform/corda/4.9/enterprise/key-concepts-flows.md b/content/en/platform/corda/4.9/enterprise/key-concepts-flows.md index 9794ee4b311..3f0a5bbda85 100644 --- a/content/en/platform/corda/4.9/enterprise/key-concepts-flows.md +++ b/content/en/platform/corda/4.9/enterprise/key-concepts-flows.md @@ -35,7 +35,7 @@ must specify what information needs to be sent, to which counterparties, and in Here is a visualisation of Alice and Bob agreeing a ledger update using this process: -{{< figure alt="flow" width=80% zoom="/en/images/flow.gif" >}} +{{< figure alt="flow" width=80% src="/en/images/flow.gif" >}} ## The flow framework @@ -44,7 +44,7 @@ of steps that tells a node how to achieve a specific ledger update, such as issu Here is a diagram showing the flow's steps used between Alice and Bob to perform the ledger update: -{{< figure alt="flow sequence" width=80% zoom="/en/images/flow-sequence.png" >}} +{{< figure alt="flow sequence" width=80% src="/en/images/flow-sequence.png" >}} ## Running flows diff --git a/content/en/platform/corda/4.9/enterprise/key-concepts-ledger.md b/content/en/platform/corda/4.9/enterprise/key-concepts-ledger.md index 78bdbb4cb00..59672fc13d6 100644 --- a/content/en/platform/corda/4.9/enterprise/key-concepts-ledger.md +++ b/content/en/platform/corda/4.9/enterprise/key-concepts-ledger.md @@ -39,7 +39,7 @@ loan are Alice and Bob, then they are the only nodes that ever see or store this This diagram shows a network with five nodes (Alice, Bob, Carl, Demi, and Ed). Each numbered circle on an intersection represents a fact shared between two or more nodes: -{{< figure alt="ledger venn" width=80% zoom="/en/images/ledger-venn.png" >}} +{{< figure alt="ledger venn" width=80% src="/en/images/ledger-venn.png" >}} In the diagram, facts 1 and 7 are known by both Alice and Bob. Alice only shares facts with Bob, Alice doesn't share any facts with Carl, Demi, or Ed. @@ -56,7 +56,7 @@ each node maintains its own vault, which contains all of its known facts. You can think of a vault as being a database or simple table. In this diagram, facts 1 and 7 appear on both Alice's vault and Bob's vault, and are therefore shared facts: -{{< figure alt="ledger table" width=80% zoom="/en/images/ledger-table.png" >}} +{{< figure alt="ledger table" width=80% src="/en/images/ledger-table.png" >}} When multiple nodes on a network share an evolving fact, the changes to the fact update at the same time in each node's vault. This means that Alice and Bob will both see an *identical version* of shared facts 1 and 7. diff --git a/content/en/platform/corda/4.9/enterprise/key-concepts-node.md b/content/en/platform/corda/4.9/enterprise/key-concepts-node.md index 2cc8f1e772d..5a9b01b70de 100644 --- a/content/en/platform/corda/4.9/enterprise/key-concepts-node.md +++ b/content/en/platform/corda/4.9/enterprise/key-concepts-node.md @@ -35,7 +35,7 @@ title: Nodes A Corda node runs within a Java Virtual Machine (JVM) runtime environment with a [unique network identity]({{< relref "key-concepts-ecosystem.md#node-identities" >}}). JVM runtime environments provide a consistent platform on which you can run and deploy Java applications, such as Corda services and CorDapps. Here is a visualization of the node’s internal architecture: -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" >}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" >}} The core elements of the architecture are: diff --git a/content/en/platform/corda/4.9/enterprise/key-concepts-states.md b/content/en/platform/corda/4.9/enterprise/key-concepts-states.md index 0d4208d6e65..140d2773781 100644 --- a/content/en/platform/corda/4.9/enterprise/key-concepts-states.md +++ b/content/en/platform/corda/4.9/enterprise/key-concepts-states.md @@ -35,7 +35,7 @@ You can use states to represent any type of data, and any kind of fact. For exam This state represents an IOU—an agreement that Alice owes Bob £10: -{{< figure alt="state" width=80% zoom="/en/images/state.png" >}} +{{< figure alt="state" width=80% src="/en/images/state.png" >}} In addition to information about the fact, the state contains a reference to the **[contract]({{< relref "key-concepts-contracts.md" >}})**. Contracts govern the evolution of states. @@ -47,14 +47,14 @@ When a fact changes, one of the state's participants creates a new state and mar For example, if Alice pays Bob £5, the state sequence would be: -{{< figure alt="state sequence" width=80% zoom="/en/images/state-sequence.png" >}} +{{< figure alt="state sequence" width=80% src="/en/images/state-sequence.png" >}} ## The vault Each node on the network maintains a **vault**. This is the node's database used to store current and historic states where the node is a participant. For example: -{{< figure alt="vault simple" width=80% zoom="/en/images/vault-simple.png" >}} +{{< figure alt="vault simple" width=80% src="/en/images/vault-simple.png" >}} From each node's point of view, the ledger is the current (non-historic) states where that node is a participant. diff --git a/content/en/platform/corda/4.9/enterprise/key-concepts-tearoffs.md b/content/en/platform/corda/4.9/enterprise/key-concepts-tearoffs.md index 30dadf29e3b..48bf97c2554 100644 --- a/content/en/platform/corda/4.9/enterprise/key-concepts-tearoffs.md +++ b/content/en/platform/corda/4.9/enterprise/key-concepts-tearoffs.md @@ -39,7 +39,7 @@ Merkle trees split transactions into "leaves". Each leaf contains either an input, an output, a command, or an attachment. The final nested tree structure also contains the other fields of the transaction, such as the time window, the notary, and the required signers. The only component type that requires two trees instead of one is the command, which is split into command data and required signers for visibility purposes. -{{< figure alt="merkleTreeFull" width=80% zoom="/en/images/merkleTreeFull.png" >}} +{{< figure alt="merkleTreeFull" width=80% src="/en/images/merkleTreeFull.png" >}} Corda uses one nested Merkle tree per component type. A component sub-tree is generated for each component type (for example, inputs, outputs, or attachments). The roots of these sub-trees @@ -65,7 +65,7 @@ obtained belongs to that particular transaction. In this example, assume that only the first command should be visible to the oracle. You must provide guarantees that all the commands the oracle needs to sign are visible to the oracle entity, but no other data. The transaction would be represented in the Merkle tree structure like this: -{{< figure alt="SubMerkleTree Oracle" width=80% zoom="/en/images/SubMerkleTree_Oracle.png" >}} +{{< figure alt="SubMerkleTree Oracle" width=80% src="/en/images/SubMerkleTree_Oracle.png" >}} The blue nodes and `H(c2)` are provided to the oracle service, while the black ones are omitted. The oracle needs `H(c2)` so it can compute `H(commandData)` without being to able to see the second command. At the same time, this ensures that `CommandData1` is part of the transaction. All signers are visible as @@ -79,4 +79,4 @@ To send the same transaction to a non-validating notary, hide all components apart from input states, time window, and the notary information. This data is enough for the notary to know which input states to check for double-spending, if the time-window is valid, and if the transaction is being notarized by the correct notary. -{{< figure alt="SubMerkleTree Notary" width=80% zoom="/en/images/SubMerkleTree_Notary.png" >}} +{{< figure alt="SubMerkleTree Notary" width=80% src="/en/images/SubMerkleTree_Notary.png" >}} diff --git a/content/en/platform/corda/4.9/enterprise/key-concepts-time-windows.md b/content/en/platform/corda/4.9/enterprise/key-concepts-time-windows.md index 388a9227dba..fdd0198f46d 100644 --- a/content/en/platform/corda/4.9/enterprise/key-concepts-time-windows.md +++ b/content/en/platform/corda/4.9/enterprise/key-concepts-time-windows.md @@ -46,7 +46,7 @@ trade, or requesting human sign-off. Times in transactions are specified as time *windows*, not absolute times. Time windows can be open-ended, and specify only “before” **or** “after”, or they can be fully bounded. -{{< figure alt="time window" width=80% zoom="/en/images/time-window.gif" >}} +{{< figure alt="time window" width=80% src="/en/images/time-window.gif" >}} When both a before and an after time are included the transaction occurred at some point within that time window. diff --git a/content/en/platform/corda/4.9/enterprise/key-concepts-transactions.md b/content/en/platform/corda/4.9/enterprise/key-concepts-transactions.md index bfc0fa3e2e0..ee4c0f4968e 100644 --- a/content/en/platform/corda/4.9/enterprise/key-concepts-transactions.md +++ b/content/en/platform/corda/4.9/enterprise/key-concepts-transactions.md @@ -37,7 +37,7 @@ Every [state]({{< relref "key-concepts-states.md" >}}) is *immutable*—it can't Here is an example of a transaction with two inputs and two outputs: -{{< figure alt="basic tx" width=80% zoom="/en/images/basic-tx.png" >}} +{{< figure alt="basic tx" width=80% src="/en/images/basic-tx.png" >}} A transaction can contain any number of inputs, outputs and references of any type. Transactions can: * Include different types of states representing multiple financial instruments, such as cash or bonds. @@ -65,21 +65,21 @@ Input state references consist of: You can see how this works in this example transaction: -{{< figure alt="tx chain" width=80% zoom="/en/images/tx-chain.png" >}} +{{< figure alt="tx chain" width=80% src="/en/images/tx-chain.png" >}} ## Committing transactions to the ledger Initially, a transaction is only a proposal to update the ledger. It represents the future state of the ledger desired by the transaction builders. -{{< figure alt="uncommitted tx" width=80% zoom="/en/images/uncommitted_tx.png" >}} +{{< figure alt="uncommitted tx" width=80% src="/en/images/uncommitted_tx.png" >}} To be committed to the ledger, the transaction must receive signatures from all the *required signers*. Each required signer appends their signature to the transaction to approve the proposal. -{{< figure alt="tx with sigs" width=80% zoom="/en/images/tx_with_sigs.png" >}} +{{< figure alt="tx with sigs" width=80% src="/en/images/tx_with_sigs.png" >}} If the transaction gathers the required signatures, it is committed: -{{< figure alt="committed tx" width=80% zoom="/en/images/committed_tx.png" >}} +{{< figure alt="committed tx" width=80% src="/en/images/committed_tx.png" >}} This means that: * The transaction’s inputs are marked as historic, and cannot be used in any future transactions. @@ -121,7 +121,7 @@ For example, suppose Alice uses $5 cash to pay off $5 of an IOU with Bob. This transaction contains a *settlement command* which reduces the amount outstanding on the IOU, and a *payment command* which changes the ownership of $5 from Alice to Bob. It also has two supporting attachments, and is notarized by `NotaryClusterA` if the notary pool receives it within the specified time window: -{{< figure alt="full tx" width=80% zoom="/en/images/full-tx.png" >}} +{{< figure alt="full tx" width=80% src="/en/images/full-tx.png" >}} ### Commands @@ -145,7 +145,7 @@ listed in the commands, you get the list of the transaction’s required signers This situation would look like this: -{{< figure alt="commands" width=80% zoom="/en/images/commands.png" >}} +{{< figure alt="commands" width=80% src="/en/images/commands.png" >}} ### Attachments diff --git a/content/en/platform/corda/4.9/enterprise/key-concepts-vault.md b/content/en/platform/corda/4.9/enterprise/key-concepts-vault.md index b1675db878b..a38bb0f6d61 100644 --- a/content/en/platform/corda/4.9/enterprise/key-concepts-vault.md +++ b/content/en/platform/corda/4.9/enterprise/key-concepts-vault.md @@ -47,7 +47,7 @@ The vault supports the management of data in both authoritative **on-ledger** fo This diagram illustrates the breakdown of the vault into sub-system components: -{{< figure alt="vault" width=80% zoom="/en/images/vault.png" >}} +{{< figure alt="vault" width=80% src="/en/images/vault.png" >}} You can see: diff --git a/content/en/platform/corda/4.9/enterprise/network-builder.md b/content/en/platform/corda/4.9/enterprise/network-builder.md index cd43d4b47c9..5c5f65376d4 100644 --- a/content/en/platform/corda/4.9/enterprise/network-builder.md +++ b/content/en/platform/corda/4.9/enterprise/network-builder.md @@ -21,7 +21,7 @@ title: Corda Network Builder The Corda Network Builder is a tool for building Corda networks for testing purposes. It leverages Docker and containers to abstract the complexity of managing a distributed network away from the user. -{{< figure alt="network builder v4" width=80% zoom="/en/images/network-builder-v4.png" >}} +{{< figure alt="network builder v4" width=80% src="/en/images/network-builder-v4.png" >}} The network you build will either be made up of local `Docker` nodes *or* of nodes spread across Azure containers. For each node a separate Docker image is built based on [corda/corda-zulu-java1.8-4.4](https://hub.docker.com/r/corda/corda-zulu-java1.8-4.4). diff --git a/content/en/platform/corda/4.9/enterprise/network/cipher-suites.md b/content/en/platform/corda/4.9/enterprise/network/cipher-suites.md index ef882c1f9bd..6b85c261449 100644 --- a/content/en/platform/corda/4.9/enterprise/network/cipher-suites.md +++ b/content/en/platform/corda/4.9/enterprise/network/cipher-suites.md @@ -54,7 +54,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, see [Network certificates]({{< relref "permissioning.md" >}})): -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Supported cipher suites diff --git a/content/en/platform/corda/4.9/enterprise/network/permissioning.md b/content/en/platform/corda/4.9/enterprise/network/permissioning.md index d4e83a5694a..d504c9696e4 100644 --- a/content/en/platform/corda/4.9/enterprise/network/permissioning.md +++ b/content/en/platform/corda/4.9/enterprise/network/permissioning.md @@ -42,7 +42,7 @@ certificates. We can visualise the permissioning structure as follows: -{{< figure alt="certificate structure" width=80% zoom="../resources/certificate_structure.png" >}} +{{< figure alt="certificate structure" width=80% src="../resources/certificate_structure.png" >}} ## Key pair and certificate formats diff --git a/content/en/platform/corda/4.9/enterprise/node/collaborative-recovery/deployment-and-operations.md b/content/en/platform/corda/4.9/enterprise/node/collaborative-recovery/deployment-and-operations.md index 3c86da80d0e..cf78656e8fb 100644 --- a/content/en/platform/corda/4.9/enterprise/node/collaborative-recovery/deployment-and-operations.md +++ b/content/en/platform/corda/4.9/enterprise/node/collaborative-recovery/deployment-and-operations.md @@ -90,7 +90,7 @@ The space complexities are outlined below: You can see a suggested high-level, disaster recovery setup in the diagram below. -{{< figure alt="Suggested Disaster Recovery Setup" width=80% zoom="../../resources/collaborative-recovery/dr-setup.png" >}} +{{< figure alt="Suggested Disaster Recovery Setup" width=80% src="../../resources/collaborative-recovery/dr-setup.png" >}} The exact setup you choose is likely to be influenced by your organisation and business requirements, but the key points are: diff --git a/content/en/platform/corda/4.9/enterprise/node/collaborative-recovery/introduction-cr.md b/content/en/platform/corda/4.9/enterprise/node/collaborative-recovery/introduction-cr.md index 3cf3076de06..2213e6ec79b 100644 --- a/content/en/platform/corda/4.9/enterprise/node/collaborative-recovery/introduction-cr.md +++ b/content/en/platform/corda/4.9/enterprise/node/collaborative-recovery/introduction-cr.md @@ -153,7 +153,7 @@ inbound / outbound reconciliations and also supports different throttling techni A high-level, peer-to-peer reconciliation flow is depicted in the diagram below. **LedgerSync** can run multiple reconciliations concurrently, up to the limit configured by the user. -{{< figure alt="Peer-to-Peer Reconciliation Flow" width=80% zoom="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} +{{< figure alt="Peer-to-Peer Reconciliation Flow" width=80% src="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} ### LedgerRecover @@ -176,7 +176,7 @@ supports different types of throttling to prevent accidental abuse of the functi A high-level, peer-to-peer automatic recovery flow is depicted in the diagram below. -{{< figure alt="Peer-to-Peer Automatic Recovery Flow" width=80% zoom="../../resources/collaborative-recovery/automatic-ledger-recover-flow.png" >}} +{{< figure alt="Peer-to-Peer Automatic Recovery Flow" width=80% src="../../resources/collaborative-recovery/automatic-ledger-recover-flow.png" >}} {{< attention >}} Even though the recovery flow contains the word "automatic" in its name, it can only be started manually. @@ -195,7 +195,7 @@ the import has been stopped halfway through. A high-level, peer-to-peer manual recovery flow is depicted in the diagram below. -{{< figure alt="Peer-to-Peer Manual Recovery Flow" width=80% zoom="../../resources/collaborative-recovery/manual-ledger-recover-flow.png" >}} +{{< figure alt="Peer-to-Peer Manual Recovery Flow" width=80% src="../../resources/collaborative-recovery/manual-ledger-recover-flow.png" >}} ### Supported disaster recovery scenarios diff --git a/content/en/platform/corda/4.9/enterprise/node/collaborative-recovery/ledger-sync.md b/content/en/platform/corda/4.9/enterprise/node/collaborative-recovery/ledger-sync.md index e0d5ae28111..158f915c99c 100644 --- a/content/en/platform/corda/4.9/enterprise/node/collaborative-recovery/ledger-sync.md +++ b/content/en/platform/corda/4.9/enterprise/node/collaborative-recovery/ledger-sync.md @@ -28,7 +28,7 @@ All reconciliations are added to a bounded execution pool, which is configurable This means the node that requested the reconciliation will be notified if the responding node has transactions that the requesting node does not. The responding node will not be notified if the requesting node has transactions that the responding node does not. -{{< figure alt="LedgerSync Flow" width=80% zoom="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} +{{< figure alt="LedgerSync Flow" width=80% src="../../resources/collaborative-recovery/ledger-sync-flow.png" >}} ### Integration with Archiving diff --git a/content/en/platform/corda/4.9/enterprise/node/component-topology.md b/content/en/platform/corda/4.9/enterprise/node/component-topology.md index efff586bae8..e239c65d9d2 100644 --- a/content/en/platform/corda/4.9/enterprise/node/component-topology.md +++ b/content/en/platform/corda/4.9/enterprise/node/component-topology.md @@ -33,7 +33,7 @@ The key node components and services are: * The Corda firewall -{{< figure alt="node architecture" width=80% zoom="/en/images/node-architecture.png" figcaption="Node internal architecture.">}} +{{< figure alt="node architecture" width=80% src="/en/images/node-architecture.png" figcaption="Node internal architecture.">}} ### CorDapps @@ -83,14 +83,14 @@ Nodes communicate with other nodes using asynchronous AMQP/TLS 1.2 protocols. HT Nodes communicate with client applications using RPC calls. -{{< figure alt="overview" width=80% zoom="../resources/overview.png" >}} +{{< figure alt="overview" width=80% src="../resources/overview.png" >}} ## Typical node deployments In most cases, nodes are deployed with this architecture: -{{< figure alt="nodebridgefloat nbrs" width=80% zoom="../resources/nodebridgefloat_nbrs.png" figcaption="A typical node deployment.">}} +{{< figure alt="nodebridgefloat nbrs" width=80% src="../resources/nodebridgefloat_nbrs.png" figcaption="A typical node deployment.">}} Most production deployments of Corda Enterprise include nodes, vaults, and firewalls. diff --git a/content/en/platform/corda/4.9/enterprise/node/corda-firewall-component.md b/content/en/platform/corda/4.9/enterprise/node/corda-firewall-component.md index 6d1f2be28e7..e44c0a40317 100644 --- a/content/en/platform/corda/4.9/enterprise/node/corda-firewall-component.md +++ b/content/en/platform/corda/4.9/enterprise/node/corda-firewall-component.md @@ -140,7 +140,7 @@ Artemis with the node as TLS endpoint and to have the outgoing packets use the i Typically this should only be used for easy development, or for organisations evaluating on Open Source Corda, where this is the only available option: -{{< figure alt="node embedded bridge" width=80% zoom="/en/images/node_embedded_bridge.png" >}} +{{< figure alt="node embedded bridge" width=80% src="/en/images/node_embedded_bridge.png" >}} ### Node + Combined Bridge/Float (no DMZ) @@ -170,7 +170,7 @@ Then configure an all-in-one bridge to point at this node’s `messagingServerAd {{< /note >}} -{{< figure alt="simple bridge" width=80% zoom="/en/images/simple_bridge.png" >}} +{{< figure alt="simple bridge" width=80% src="/en/images/simple_bridge.png" >}} #### node.conf @@ -238,7 +238,7 @@ key, the tunnel link should use a private set of link specific keys and certific dynamically with the official TLS key when activated via the tunnel and this key will never be stored in the DMZ: {{< /note >}} -{{< figure alt="node bridge float" width=80% zoom="/en/images/node_bridge_float.png" >}} +{{< figure alt="node bridge float" width=80% src="/en/images/node_bridge_float.png" >}} #### node.conf @@ -326,7 +326,7 @@ Some organisations require dynamic outgoing connections to operate via a SOCKS p by adding extra information to the `outboundConfig` section of the bridge process. A simplified example deployment is shown here to highlight the option: -{{< figure alt="socks proxy" width=80% zoom="/en/images/socks_proxy.png" >}} +{{< figure alt="socks proxy" width=80% src="/en/images/socks_proxy.png" >}} #### node.conf @@ -426,7 +426,7 @@ Highlighted in the diagram is the addition of the `haConfig` section to point at addresses in the `alternateArtemisAddresses` to allow node failover and in the `floatAddresses` to point at a pool of DMZ float processes. -{{< figure alt="ha nodes" width=80% zoom="/en/images/ha_nodes.png" >}} +{{< figure alt="ha nodes" width=80% src="/en/images/ha_nodes.png" >}} #### node.conf @@ -563,7 +563,7 @@ It is possible to allow two or more Corda nodes (HA and/or non-HA) handle outgoi an external Artemis messaging broker which can be easily configured using the ha-tool. For more information, please see HA Utilities. While this example is the simplest deployment possible with a shared bridge, any other configuration previously presented can be created. -{{< figure alt="multiple nodes no ha" width=80% zoom="/en/images/multiple_nodes_no_ha.png" >}} +{{< figure alt="multiple nodes no ha" width=80% src="/en/images/multiple_nodes_no_ha.png" >}} #### bank-a-node.conf diff --git a/content/en/platform/corda/4.9/enterprise/node/corda-firewall-configuration-file.md b/content/en/platform/corda/4.9/enterprise/node/corda-firewall-configuration-file.md index 5ddd8e71572..7b6e5008864 100644 --- a/content/en/platform/corda/4.9/enterprise/node/corda-firewall-configuration-file.md +++ b/content/en/platform/corda/4.9/enterprise/node/corda-firewall-configuration-file.md @@ -132,14 +132,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -152,7 +152,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/platform/corda/4.9/enterprise/node/deploy/env-prod-test.md b/content/en/platform/corda/4.9/enterprise/node/deploy/env-prod-test.md index a22b5eec39d..e77888df770 100644 --- a/content/en/platform/corda/4.9/enterprise/node/deploy/env-prod-test.md +++ b/content/en/platform/corda/4.9/enterprise/node/deploy/env-prod-test.md @@ -33,12 +33,12 @@ There are alternative approaches to how these components are deployed. For the p When deploying Corda Enterprise in a testing environment the Node, Bridge, and Float components should be deployed in a non-HA configuration as shown in the following diagram. -{{< figure alt="nonha" width=80% zoom="../../resources/nonha.png" >}} +{{< figure alt="nonha" width=80% src="../../resources/nonha.png" >}} When deploying Corda Enterprise in a production environment, the Node, Bridge, and Float components should be deployed in a high-availability configuration. -{{< figure alt="ha" width=80% zoom="../../resources/ha.png" >}} +{{< figure alt="ha" width=80% src="../../resources/ha.png" >}} ### Deployment details @@ -205,7 +205,7 @@ This is a sample `node.conf` which details a configuration connecting to a Corda In a bank environment there will typically be several layers of security protecting the firms data. -{{< figure alt="cordarch" width=80% zoom="../../resources/cordarch.png" >}} +{{< figure alt="cordarch" width=80% src="../../resources/cordarch.png" >}} *Network Authentication* @@ -219,7 +219,7 @@ In a bank environment there will typically be several layers of security protect * Corda PKI Authentication issued by Corda Network can link the Node and Bridge i.e. the red keys indicated below truststore and sslkeystore * Local PKI Authentication issued by separate CA will link the Bridge and Float i.e the purple keys indicated below trust and Bridge. -{{< figure alt="firewallpki" width=80% zoom="../../resources/firewallpki.png" >}} +{{< figure alt="firewallpki" width=80% src="../../resources/firewallpki.png" >}} The key thing is to look at this from the perspective of a bank implementing these Corda and Local PKI keys. @@ -374,7 +374,7 @@ Administrative logins with the Corda node happen via ssh whose port is configure The following image may be helpful in ensuring alignment between the Node, Bridge and Float configuration files. -{{< figure alt="CordaFirewallConfigAlign" width=80% zoom="../../resources/CordaFirewallConfigAlign.png" >}} +{{< figure alt="CordaFirewallConfigAlign" width=80% src="../../resources/CordaFirewallConfigAlign.png" >}} {{< note >}} **p2pAddress** reflects the **publicly accessible address**, which may or may not be the Float inboundConfig.listeningAddress. If there is an internet firewall configured in front of the Float then ask the Network Administrator for the public address that routes to the Float’s **listeningAddress**, and use that public address for your **p2pAddress**. diff --git a/content/en/platform/corda/4.9/enterprise/node/deploy/hot-cold-deployment.md b/content/en/platform/corda/4.9/enterprise/node/deploy/hot-cold-deployment.md index 67023ebf63e..3299c22b7e3 100644 --- a/content/en/platform/corda/4.9/enterprise/node/deploy/hot-cold-deployment.md +++ b/content/en/platform/corda/4.9/enterprise/node/deploy/hot-cold-deployment.md @@ -36,7 +36,7 @@ resources for both **Microsoft Azure** and **Amazon Web Services**. The image be result from following the guide. There will be two Corda Enterprise nodes, one active and the other inactive. Each node will represent the same legal identity inside the Corda network. Both will share a database and a network file system. -{{< figure alt="hot cold" width=80% zoom="../../resources/hot-cold.png" >}} +{{< figure alt="hot cold" width=80% src="../../resources/hot-cold.png" >}} ## Configuring the load balancer diff --git a/content/en/platform/corda/4.9/enterprise/node/operating/node-administration.md b/content/en/platform/corda/4.9/enterprise/node/operating/node-administration.md index f1e2336d0d6..61adf70d7de 100644 --- a/content/en/platform/corda/4.9/enterprise/node/operating/node-administration.md +++ b/content/en/platform/corda/4.9/enterprise/node/operating/node-administration.md @@ -245,7 +245,7 @@ When starting Corda nodes using the ‘driver DSL’, you should see a startup m The following diagram illustrates Corda flow metrics visualized using hawtio: -{{< figure alt="hawtio jmx" width=80% zoom="/en/images/hawtio-jmx.png" >}} +{{< figure alt="hawtio jmx" width=80% src="/en/images/hawtio-jmx.png" >}} ### Monitoring via Graphite diff --git a/content/en/platform/corda/4.9/enterprise/node/operating/node-database-tables.md b/content/en/platform/corda/4.9/enterprise/node/operating/node-database-tables.md index 87fdad7b69d..f92950bc242 100644 --- a/content/en/platform/corda/4.9/enterprise/node/operating/node-database-tables.md +++ b/content/en/platform/corda/4.9/enterprise/node/operating/node-database-tables.md @@ -42,7 +42,7 @@ By calling `rpc.clearNetworkMapCache()` all these tables will be cleared and rec Read more in [Network map]({{< relref "../../network/network-map.md" >}}). -{{< figure alt="node info tables" width=80% zoom="/en/images/node_info_tables.png" >}} +{{< figure alt="node info tables" width=80% src="/en/images/node_info_tables.png" >}} {{< table >}} @@ -171,7 +171,7 @@ Read more in [Ledger]({{< relref "../../key-concepts-ledger.md" >}}). Read more in [Working with attachments]({{< relref "../../get-started/tutorials/supplementary-tutorials/tutorial-attachments.md" >}}) and [Node services]({{< relref "../../node-services.md" >}}). -{{< figure alt="attachments tables" width=80% zoom="/en/images/attachments_tables.png" >}} +{{< figure alt="attachments tables" width=80% src="/en/images/attachments_tables.png" >}} {{< table >}} @@ -467,7 +467,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Fungible states -{{< figure alt="vault fungible states" width=80% zoom="/en/images/vault_fungible_states.png" >}} +{{< figure alt="vault fungible states" width=80% src="/en/images/vault_fungible_states.png" >}} {{< table >}} @@ -496,7 +496,7 @@ The actual content of the states can be retrieved from the `NODE_TRANSACTIONS` t ### Linear states -{{< figure alt="vault linear states" width=80% zoom="/en/images/vault_linear_states.png" >}} +{{< figure alt="vault linear states" width=80% src="/en/images/vault_linear_states.png" >}} {{< table >}} diff --git a/content/en/platform/corda/4.9/enterprise/node/pki-guide.md b/content/en/platform/corda/4.9/enterprise/node/pki-guide.md index 69f0eefac7f..a2260be8fb3 100644 --- a/content/en/platform/corda/4.9/enterprise/node/pki-guide.md +++ b/content/en/platform/corda/4.9/enterprise/node/pki-guide.md @@ -54,7 +54,7 @@ as they root to the same certificate. Other than that, Corda nodes stay agnostic to the certificate hierarchy (in particular the depth of the certificate hierarchy tree). -{{< figure alt="hierarchy agnostic" width=80% zoom="../resources/hierarchy-agnostic.png" >}} +{{< figure alt="hierarchy agnostic" width=80% src="../resources/hierarchy-agnostic.png" >}} At the time of writing this document, the Corda Network assumes the certificate hierarchy that can be found in the [Certificate hierarchy guide]({{< relref "../network/permissioning.md#certificate-hierarchy" >}}). @@ -69,7 +69,7 @@ The network operator is responsible for certificate issuance and maintenance for at the Identity Manager and Network Map certificates. The rest of the certificate chain (i.e. every certificate below the Identity Manager certificate) falls into node operator responsibility. -{{< figure alt="tls hierarchy" width=80% zoom="../resources/tls-hierarchy.png" >}} +{{< figure alt="tls hierarchy" width=80% src="../resources/tls-hierarchy.png" >}} The certificate revocation list verification applies to the entire chain. This means that every certificate in the chain is going to be validated against the corresponding certificate revocation list during the SSL handshake. Consequently, this means that a node operator is expected to provide and maintain the certificate revocation list for the Node CA. @@ -87,7 +87,7 @@ During the certificate revocation list validation process the trust store is con As an example, let us consider the following certificate hierarchy: -{{< figure alt="example hierarchy" width=80% zoom="../resources/example-hierarchy.png" >}} +{{< figure alt="example hierarchy" width=80% src="../resources/example-hierarchy.png" >}} The certificate hierarchy presented above is currently (as of the time of writing this document) used in the Corda Network. It follows practices applicable for certificate authorities providing a balance between security and simplicity of usage. In this scenario, a network operator wants to create a CA hierarchy where the self-signed Root CA issues a certificate for the Subordinate CA which in turn issues diff --git a/content/en/platform/corda/4.9/enterprise/notary-healthcheck.md b/content/en/platform/corda/4.9/enterprise/notary-healthcheck.md index 32724a1af79..27b4502264c 100644 --- a/content/en/platform/corda/4.9/enterprise/notary-healthcheck.md +++ b/content/en/platform/corda/4.9/enterprise/notary-healthcheck.md @@ -171,4 +171,4 @@ monitor notary health via a dashboard or hook up an alerter. As an example, this view on a failing notary check. Note the metrics for *success*, *fail*, *inflight*, and *maxinflightTime* for the notary service and the cluster members on the left hand side. -{{< figure alt="hawtio healthcheck" width=80% zoom="./resources/hawtio-healthcheck.png" >}} +{{< figure alt="hawtio healthcheck" width=80% src="./resources/hawtio-healthcheck.png" >}} diff --git a/content/en/platform/corda/4.9/enterprise/notary/backup-restore.md b/content/en/platform/corda/4.9/enterprise/notary/backup-restore.md index 1fa7ce6d456..56fca32623e 100644 --- a/content/en/platform/corda/4.9/enterprise/notary/backup-restore.md +++ b/content/en/platform/corda/4.9/enterprise/notary/backup-restore.md @@ -29,7 +29,7 @@ Additionally, it is critical to have a backup of the Notary Service identity pri The following diagram highlights in blue which storage components should be backed up. -{{< figure alt="storage components" width=80% zoom="../resources/storage-components.png" >}} +{{< figure alt="storage components" width=80% src="../resources/storage-components.png" >}} Note that for regular nodes it is very important to back up the Messaging Broker (Artemis) folder and the local Database, but for HA notary nodes that are purely used for notarisation purposes that is not needed. To summarise: diff --git a/content/en/platform/corda/4.9/enterprise/notary/ha-notary-service-overview.md b/content/en/platform/corda/4.9/enterprise/notary/ha-notary-service-overview.md index 680ce4913df..a5cc2a15a25 100644 --- a/content/en/platform/corda/4.9/enterprise/notary/ha-notary-service-overview.md +++ b/content/en/platform/corda/4.9/enterprise/notary/ha-notary-service-overview.md @@ -60,7 +60,7 @@ database to store its node state (e.g. its identity information). We can visualise this set-up as follows, with the regular Corda nodes in green, the Corda notary worker nodes in red, and the standard node databases and notary state database replicas in blue. -{{< figure alt="ha notary overview2" width=80% zoom="../resources/ha-notary-overview2.png" >}} +{{< figure alt="ha notary overview2" width=80% src="../resources/ha-notary-overview2.png" >}} Nodes requesting notarisation from a highly-available notary will connect to the notary workers in round-robin fashion. Provided there are multiple notary workers and the notary state database is configured to be highly-available, the overall notary service @@ -73,7 +73,7 @@ In production, R3 recommends running five or more replicas in the notary state d If desired, you can choose to run each database server and its Corda notary worker on the same machine: -{{< figure alt="ha notary colocated" width=80% zoom="../resources/ha-notary-colocated.png" >}} +{{< figure alt="ha notary colocated" width=80% src="../resources/ha-notary-colocated.png" >}} ## Notary configuration diff --git a/content/en/platform/corda/4.9/enterprise/notary/hsm-support.md b/content/en/platform/corda/4.9/enterprise/notary/hsm-support.md index 948973f572a..9fdf0e5fb3a 100644 --- a/content/en/platform/corda/4.9/enterprise/notary/hsm-support.md +++ b/content/en/platform/corda/4.9/enterprise/notary/hsm-support.md @@ -14,7 +14,7 @@ weight: 3 ## Overview -{{< figure alt="hsm support" width=80% zoom="../resources/hsm-support.png" >}} +{{< figure alt="hsm support" width=80% src="../resources/hsm-support.png" >}} Two notary workers and their relevant cryptographic keys used for P2P messaging and transaction signing. The red rectangles represent the Corda notary worker services. The distinct identity keys are represented by rectangles in green and yellow and the shared key of the notary service identity is drawn in blue. Their cryptographic keys are held in a single HSM. diff --git a/content/en/platform/corda/4.9/enterprise/operations/deployment/firewall-deployment.md b/content/en/platform/corda/4.9/enterprise/operations/deployment/firewall-deployment.md index 4debc923dc5..265d5fa5fc9 100644 --- a/content/en/platform/corda/4.9/enterprise/operations/deployment/firewall-deployment.md +++ b/content/en/platform/corda/4.9/enterprise/operations/deployment/firewall-deployment.md @@ -130,14 +130,14 @@ This is also the recommended full enterprise deployment pattern, although there Conceptually deployment will be done as follows: -{{< figure alt="deployment concept" width=80% zoom="/en/images/deployment_concept.png" >}} +{{< figure alt="deployment concept" width=80% src="/en/images/deployment_concept.png" >}} In this example it is assumed that a large organisation is running two nodes that represent two distinct legal entities. Each node/entity has its own set of CorDapps installed and its own transaction storage (vault). These two nodes are running within a Green/Trusted Zone and can be interacted with via RPC calls from clients (either standalone or embedded in other applications). In order to be able to communicate outside of the organisation, special provisions are made in the form of Bridge, Float and SOCKS Proxy. The following diagram illustrates physical deployment of the example setup discussed above: -{{< figure alt="physical deployment" width=80% zoom="/en/images/physical_deployment.png" >}} +{{< figure alt="physical deployment" width=80% src="/en/images/physical_deployment.png" >}} {{< note >}} The arrows on the diagram show in which direction connection is initiated. The actual data exchange may then be happening in both directions. @@ -150,7 +150,7 @@ The SOCKS5 proxy is running on `vmSocks` which also resides in the DMZ. Each of the `vmInfra1` and `vmInfra2` computers host: ZooKeeper cluster participant, Bridge instance and Artemis cluster participant: -{{< figure alt="Infra" width=80% zoom="/en/images/Infra.png" >}} +{{< figure alt="Infra" width=80% src="/en/images/Infra.png" >}} To facilitate High Availability requirement deployment is split onto two data centers. {{< note >}} diff --git a/content/en/platform/corda/4.9/enterprise/performance-testing/introduction.md b/content/en/platform/corda/4.9/enterprise/performance-testing/introduction.md index 64417661d3e..2e567a16a79 100644 --- a/content/en/platform/corda/4.9/enterprise/performance-testing/introduction.md +++ b/content/en/platform/corda/4.9/enterprise/performance-testing/introduction.md @@ -110,7 +110,7 @@ The driving app sits outside the network and connects to the JMeter servers thro measuring the throughput of a node, the test definition instructs all JMeter servers to open RPC connections to one node, thus saturating the RPC handler and driving the node as hard as possible. The test might invoke a flow that can be completed locally (for example, cash issuance) or it might require exchanging P2P messages with other nodes (for example, cash payment). -{{< figure alt="jmeter network overview" width=80% zoom="../resources/jmeter-network-overview.png" >}} +{{< figure alt="jmeter network overview" width=80% src="../resources/jmeter-network-overview.png" >}} ## Performance tests diff --git a/content/en/platform/corda/4.9/enterprise/performance-testing/jmeter-samplers.md b/content/en/platform/corda/4.9/enterprise/performance-testing/jmeter-samplers.md index 6cd9e4cdf99..5866c463620 100644 --- a/content/en/platform/corda/4.9/enterprise/performance-testing/jmeter-samplers.md +++ b/content/en/platform/corda/4.9/enterprise/performance-testing/jmeter-samplers.md @@ -66,7 +66,7 @@ server, not the client machine. * `minimumNodePlatformVersion`: the minimum platform version that the JMeter client will require from the Corda nodes. It defaults to 4, which can be used to test with Corda 4.0 nodes or later. * `username`: the RPC user name of the Corda node. * `password`: the RPC password of the Corda node. -{{< figure alt="empty flow sampler" width=80% zoom="../resources/empty-flow-sampler.png" >}} +{{< figure alt="empty flow sampler" width=80% src="../resources/empty-flow-sampler.png" >}} * `CashIssueSampler`: this sampler client has the class name `com.r3.corda.jmeter.CashIssueSampler` and starts the flow `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueFlow`. This flow self-issues 1.1 billion cash tokens on the node it is running on, and stores it in the vault. In addition to the common properties described for `EmptyFlowSampler` above, this sampler client also requires: * `notaryName`: the X500 name of the notary that is acceptable to transfer cash tokens issued via this sampler. Issuing tokens does not need to be notarised, and therefore invoking this sampler does not create traffic to the notary. However, the notary is stored as part of the cash state and must be valid to do anything else with the cash state, therefore this sampler checks the notary identity against the network parameters of the node. * `CashIssueAndPaySampler`: this sampler client has the classname `com.r3.corda.jmeter.CashIssueAndPaySampler` and, depending on its parameters, it can start either of these flows - `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndPaymentFlow` or `com.r3.corda.enterprise.perftestcordapp.flows.CashIssueAndpaymentNoSelection`. Either way it issues 2 million dollars in tokens and then transfers the sum to a configurable other node, thus invoking the full vault access, peer-to-peer communication and notarisation cycle. In addition to the parameters required for `CashIssueSampler`, this sampler also requires: diff --git a/content/en/platform/corda/4.9/enterprise/performance-testing/jmeter-testplans.md b/content/en/platform/corda/4.9/enterprise/performance-testing/jmeter-testplans.md index c34cd9b7615..7ebc5c6b8bb 100644 --- a/content/en/platform/corda/4.9/enterprise/performance-testing/jmeter-testplans.md +++ b/content/en/platform/corda/4.9/enterprise/performance-testing/jmeter-testplans.md @@ -25,12 +25,12 @@ The testplan is a hierarchy of configuration elements. The only elements used in *Variables*, *Thread Groups*, *Samplers* and *Listeners*. Rather than creating a new testplan from scratch, it might a good idea to take a copy of one of the provided example test plans and modify that. -{{< figure alt="jmeter testplan" width=80% zoom="../resources/jmeter-testplan.png" >}} +{{< figure alt="jmeter testplan" width=80% src="../resources/jmeter-testplan.png" >}} A variables element defines key/value pairs that can be used in all following following elements instead of string literals. They can be referenced by using a `$` sign and curly braces, e.g. `${varName}`. -{{< figure alt="variables" width=80% zoom="../resources/variables.png" >}} +{{< figure alt="variables" width=80% src="../resources/variables.png" >}} A thread group collects a set of actions that form one step in the test plan. All elements within a thread group diff --git a/content/en/platform/corda/4.9/enterprise/performance-testing/performance-results.md b/content/en/platform/corda/4.9/enterprise/performance-testing/performance-results.md index 8cb24ac8893..f469b48da15 100644 --- a/content/en/platform/corda/4.9/enterprise/performance-testing/performance-results.md +++ b/content/en/platform/corda/4.9/enterprise/performance-testing/performance-results.md @@ -40,7 +40,7 @@ the time of Corda Enterprise Edition 4 release). This is with each node running running **Microsoft SQL Server**. Similar results were obtained against the other supported databases. -{{< figure alt="ce4 comparison chart" width=80% zoom="/en/images/ce4-comparison-chart.png" >}} +{{< figure alt="ce4 comparison chart" width=80% src="/en/images/ce4-comparison-chart.png" >}} Figure 1 @@ -52,7 +52,7 @@ varies with the number of those payments combined together. This can be useful be a technique for even greater throughput. -{{< figure alt="states per second" width=80% zoom="/en/images/states-per-second.png" >}} +{{< figure alt="states per second" width=80% src="/en/images/states-per-second.png" >}} Figure 2 @@ -65,7 +65,7 @@ of Figure 3 were achieved using Corda Enterprise 3.0 on **Microsoft Azure** virt with minimal latency between the node VM and the database server VM. -{{< figure alt="comparison chart" width=80% zoom="/en/images/comparison-chart.png" >}} +{{< figure alt="comparison chart" width=80% src="/en/images/comparison-chart.png" >}} Figure 3 @@ -303,7 +303,7 @@ All these machines were 24 core (48 hyper-threads), based on 2x Intel Xeon E5-26 The first test performed was focused on the latency aspect. Load was generated from a single client initialised in a machine that was separate from the ones hosting the Corda nodes and their databases. The load consisted of a pre-defined number of flows (400) that were executed one after the other sequentially. Each one of those flows was initiated on the central exchange node, which was responsible for collecting signatures from all the parties involved and for finalising the transaction. Each of those flows performed a swap of two states between every pair of nodes, thus leading to a Corda transaction with 10 input and 10 output states. During the test setup, the necessary amount of states was initially issued and each one of those states would be swapped once during the test. In order to also measure the impact of transaction resolution, during the test setup each of these states was transferred bilaterally between the nodes in each pair ten times, thus generating a backchain of depth 10. This meant that during every Corda transaction, each node would have to resolve the backchain of the states belonging to the other pairs - so each node would have to resolve 80 states (8 nodes x 10 states each). In order to also measure the scaling with regard to the number of nodes, the exact same test was repeated with a varying number of participants, starting from 4 nodes and going up to 10. The test was also repeated three times with Corda Enterprise versions 4.3, 4.4, and 4.5. The goal was to isolate the benefits from bulk transaction resolution, introduced in version 4.4, and parallelised flows (`CollectSignaturesFlow` / `FinalityFlow`), introduced in version 4.5. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average latency of the flow that performed the asset swap in milliseconds. -{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 latency comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_latency_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.3 shows an exponential increase in the latency of the flow as the number of nodes that participate in the transaction is increased. This can be attributed to the following two reasons. Firstly, during the tests the exchange node was performing the `CollectSignaturesFlow` and `FinalityFlow` flows sequentially across the involved nodes, so the more nodes these flows had to iterate over, the more time it took. Secondly, these flows have the capability to trigger the execution of transaction resolution if they identify states for which the node is missing the provenance chain. In Corda Enterprise Edition 4.3, transaction resolution is not performed in bulk - it is performed one state at a time. As a result, every additional node causes a significant amount of extra work to be done. @@ -314,7 +314,7 @@ The main observations from the tests follow below: The second test was focused on the throughput aspect. Load was generated from multiple clients initialised on the machines that were hosting the Corda nodes, which were acting as JMeter servers orchestrated by a JMeter client running on a separate machine. The goal was to saturate the participating Corda nodes and to prevent the single client from becoming the bottleneck. During the test setup, each client issued one state to every node. Each client was then performing one flow at a time, swapping these states between the participating nodes. No backchain was generated as part of this test. As a result, the test was executed only between Corda Enterprise Edition 4.3 and Corda Enterprise Edition 4.5, and with a varying number of nodes ranging from 2 up to 10. Each of the machines driving the load was using 120 concurrent clients, which summed up to 480 concurrent clients in total. Additional measurements were performed with a varying number of clients, in order to ensure that this was the optimal number of clients to saturate the nodes without overloading them. Since the throughput was different depending on the number of participating nodes, the total number of requests was also adjusted accordingly in order to get roughly the same total duration of approximately 20 minutes. In all the scenarios, it was confirmed that the nodes had reached a stable state when the test ended. The diagram below shows the results of this test, where the *x* axis indicates the number of nodes participating in the test, and the *y* axis indicates the average throughput measured in the number of flows completed per second. -{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% zoom="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} +{{< figure alt="CE 4.3/4.5 throughput comparison chart" width=80% src="../resources/performance-testing/4-3_4-5_throughput_comparison.png" >}} The main observations from the tests follow below: * Corda Enterprise Edition 4.5 can achieve a significantly higher throughput when compared to Corda Enterprise Edition 4.3. This can be attributed to the following factors: @@ -336,9 +336,9 @@ Five different variations were tested, as follows: The purpose of this last test was to investigate the effects of these options in both throughput and latency because some of these options introduce trade-offs between these two aspects. To this end, the tests described earlier in this analysis were repeated using the variations listed above. For the latency measurements, 10 nodes were used because, thanks to the low load, there was no expectation for any big interference between nodes on the same machine. For the throughput measurements, only 4 nodes were used in order to avoid any interference between nodes on the same machine due to the high load. The results are shown in the diagrams below - the *x* axis contains the variations used, and the *y* axis shows the average throughput and latency achieved with each variation along with error bars indicating the standard deviation. -{{< figure alt="CE 4.5 variants latency comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_latency.png" >}} +{{< figure alt="CE 4.5 variants latency comparison chart" width=80% src="../resources/performance-testing/4-5_variants_latency.png" >}} -{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% zoom="../resources/performance-testing/4-5_variants_throughput.png" >}} +{{< figure alt="CE 4.5 variants throughput comparison chart" width=80% src="../resources/performance-testing/4-5_variants_throughput.png" >}} The main observations from the test are as follows: * Disabling compression leads to lower throughput and higher latency. This is expected because compression introduces a trade-off between CPU and network bandwidth utilisation and in most cases the network would prove to be a bigger bottleneck. diff --git a/content/en/platform/corda/4.9/enterprise/performance-testing/practical-considerations.md b/content/en/platform/corda/4.9/enterprise/performance-testing/practical-considerations.md index d1f4205a65f..c0c59726c38 100644 --- a/content/en/platform/corda/4.9/enterprise/performance-testing/practical-considerations.md +++ b/content/en/platform/corda/4.9/enterprise/performance-testing/practical-considerations.md @@ -94,7 +94,7 @@ To collect the output of a JMeter performance run, we need to add listeners to t This listener just lists all the runs that have been completed, one run per row, stating the thread name, sampler label, the sample time in milliseconds, the result status and the latency in milliseconds, among other (usually less useful) fields. -{{< figure alt="jmeter results table" width=80% zoom="../resources/jmeter-results-table.png" >}} +{{< figure alt="jmeter results table" width=80% src="../resources/jmeter-results-table.png" >}} This view is particularly useful when trying out any changes (new flow, new sampler, new installation) to see if it is working at all. The potential outcomes are: @@ -123,7 +123,7 @@ This listener aggregates all the runs for each thread group and the whole test p It also allows plotting these statistics in basic charts and to save the results as a csv file. This is what we use for looking at the performance results on a day to day basis. -{{< figure alt="jmeter results aggregate" width=80% zoom="../resources/jmeter-results-aggregate.png" >}} +{{< figure alt="jmeter results aggregate" width=80% src="../resources/jmeter-results-aggregate.png" >}} This listener has one line for each sampler being run as part of the test plan, and a total line summing up/averaging the results for the whole test plan. diff --git a/content/en/platform/corda/4.9/enterprise/performance-testing/r3-performance-runs.md b/content/en/platform/corda/4.9/enterprise/performance-testing/r3-performance-runs.md index da175775c83..db0cabba946 100644 --- a/content/en/platform/corda/4.9/enterprise/performance-testing/r3-performance-runs.md +++ b/content/en/platform/corda/4.9/enterprise/performance-testing/r3-performance-runs.md @@ -32,7 +32,7 @@ The performance network sits behind a firewall that allows incoming connections within the network can connect to each other on a range of ports (Corda Remote Procedure Call (RPC), Corda peer to peer connection (P2P) and JDBC connections to various database servers are all allowed). -{{< figure alt="performance cluster" width=80% zoom="../resources/performance-cluster.png" >}} +{{< figure alt="performance cluster" width=80% src="../resources/performance-cluster.png" >}} A Corda JMeter server instance is running on all 4 nodes and on the notary server. The JMeter client connects to the JMeter server instances via SSH tunnels. As the JMeter servers run within the firewalled network, they are free to diff --git a/content/en/platform/corda/4.9/enterprise/performance-testing/running-jmeter-corda.md b/content/en/platform/corda/4.9/enterprise/performance-testing/running-jmeter-corda.md index efaba05496b..10a22c4f8a8 100644 --- a/content/en/platform/corda/4.9/enterprise/performance-testing/running-jmeter-corda.md +++ b/content/en/platform/corda/4.9/enterprise/performance-testing/running-jmeter-corda.md @@ -54,7 +54,7 @@ interactively either locally or remotely, and view results. The UI has a set of quickly create or load a testplan, control local or remote test runs, and clear any test results collected so far. The latter is particularly important when looking at averages, as old data might skew the results being looked at. -{{< figure alt="jmeter buttons" width=80% zoom="../resources/jmeter-buttons.png" >}} +{{< figure alt="jmeter buttons" width=80% src="../resources/jmeter-buttons.png" >}} The *clear current view* button only clears the data in the currently viewed output collector - if a test plan has several output listeners defined (as in the example above, we have *Aggregate Graph*, *Graph Results* and *View Results in Table*), any collector not currently selected is not affected. *Clear all data* will clear the results from all collectors. diff --git a/content/en/platform/corda/5.1/key-concepts/cordapp-dev/ecosystem/_index.md b/content/en/platform/corda/5.1/key-concepts/cordapp-dev/ecosystem/_index.md index d13fd6adf14..09720dbfcce 100644 --- a/content/en/platform/corda/5.1/key-concepts/cordapp-dev/ecosystem/_index.md +++ b/content/en/platform/corda/5.1/key-concepts/cordapp-dev/ecosystem/_index.md @@ -41,7 +41,7 @@ A future version may support both send and send-and-receive messages. {{< figure - src="external-messaging" + src="external-messaging.png" width="40%" figcaption="External Messaging API" >}} diff --git a/content/en/platform/corda/5.2/developing-applications/cordapp-template/debugging-against-local-corda/debugging.png b/content/en/platform/corda/5.2/developing-applications/cordapp-template/debugging-against-local-corda/debugging.png new file mode 100644 index 00000000000..8702faa8246 Binary files /dev/null and b/content/en/platform/corda/5.2/developing-applications/cordapp-template/debugging-against-local-corda/debugging.png differ diff --git a/content/en/platform/corda/5.2/developing-applications/cordapp-template/debugging-against-local-corda/_index.md b/content/en/platform/corda/5.2/developing-applications/cordapp-template/debugging-against-local-corda/index.md similarity index 95% rename from content/en/platform/corda/5.2/developing-applications/cordapp-template/debugging-against-local-corda/_index.md rename to content/en/platform/corda/5.2/developing-applications/cordapp-template/debugging-against-local-corda/index.md index 6207ea1c671..6995c00671b 100644 --- a/content/en/platform/corda/5.2/developing-applications/cordapp-template/debugging-against-local-corda/_index.md +++ b/content/en/platform/corda/5.2/developing-applications/cordapp-template/debugging-against-local-corda/index.md @@ -21,7 +21,7 @@ To debug: 1. [Start the Corda combined worker using the startCorda Gradle helper]({{< relref "../running-your-first-cordapp/_index.md#starting-the-corda-combined-worker" >}}), if not already started. 2. [Deploy your CorDapp using deployCordapp]({{< relref "../running-your-first-cordapp/_index.md#deploying-a-cordapp" >}}), if not already deployed. 3. Select the `DebugCorDapp` run configuration. -{{< figure src="./overview/debugging.png" width="40%" figcaption="DebugCorDapp run configuration in IntelliJ" >}} +{{< figure src="debugging.png" width="40%" figcaption="DebugCorDapp run configuration in IntelliJ" >}} 4. Click the **Debug** button. {{< figure src="click-debug.png" width="50%" figcaption="Debug button in IntelliJ" >}} The following message is displayed to indicate a successful connection: diff --git a/content/en/platform/corda/5.2/developing-applications/cordapp-template/overview/_index.md b/content/en/platform/corda/5.2/developing-applications/cordapp-template/overview/index.md similarity index 100% rename from content/en/platform/corda/5.2/developing-applications/cordapp-template/overview/_index.md rename to content/en/platform/corda/5.2/developing-applications/cordapp-template/overview/index.md diff --git a/content/en/platform/corda/5.2/key-concepts/cordapp-dev/ecosystem/_index.md b/content/en/platform/corda/5.2/key-concepts/cordapp-dev/ecosystem/_index.md index d3ae6a84e0f..5ef35ae8414 100644 --- a/content/en/platform/corda/5.2/key-concepts/cordapp-dev/ecosystem/_index.md +++ b/content/en/platform/corda/5.2/key-concepts/cordapp-dev/ecosystem/_index.md @@ -41,7 +41,7 @@ A future version may support both send and send-and-receive messages. {{< figure - src="external-messaging" + src="external-messaging.png" width="40%" figcaption="External Messaging API" >}} diff --git a/content/en/tools/cdl/bpmn-view/corda-transactions.md b/content/en/tools/cdl/bpmn-view/corda-transactions.md index 8aadbc12d23..391979dddc3 100644 --- a/content/en/tools/cdl/bpmn-view/corda-transactions.md +++ b/content/en/tools/cdl/bpmn-view/corda-transactions.md @@ -19,7 +19,7 @@ The actions are joined with a two way dashed line. In BPMN dashed lines denote m The party that initiated the transaction is marked, and the message line is annotated on the Initiator end with a blue box giving more details about how the transaction was formed. This is typically what Flow is invoked and what the Command in the transaction should be. -{{< figure zoom="../resources/cdl-bpmn-agreement-process-corda-transactions.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-bpmn-agreement-process-corda-transactions.png" width="1000" title="Click to zoom image in new tab/window" >}} In this example you can see that the Buyer will initiate the ProposeFlow to create a Propose transaction. diff --git a/content/en/tools/cdl/bpmn-view/full-diagram.md b/content/en/tools/cdl/bpmn-view/full-diagram.md index f4eeb914332..a098e4a61d0 100644 --- a/content/en/tools/cdl/bpmn-view/full-diagram.md +++ b/content/en/tools/cdl/bpmn-view/full-diagram.md @@ -17,7 +17,7 @@ Now that almost all the components needed to complete the full BPMN diagram are The full diagram looks as follows: -{{< figure zoom="../resources/cdl-bpmn-agreement-process-full.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-bpmn-agreement-process-full.png" width="1000" title="Click to zoom image in new tab/window" >}} You can trace a number of different scenarios depending on the decisions that each of the participants takes. diff --git a/content/en/tools/cdl/bpmn-view/gateways.md b/content/en/tools/cdl/bpmn-view/gateways.md index aff68c4dc4f..ae153f677ac 100644 --- a/content/en/tools/cdl/bpmn-view/gateways.md +++ b/content/en/tools/cdl/bpmn-view/gateways.md @@ -16,6 +16,6 @@ Business process have decision points in them, decisions are represented in BPMN Using the gateway we can extend the diagram to show the next sequences of events: - {{< figure zoom="../resources/cdl-bpmn-agreement-process-decision1.png" width="1000" title="Click to zoom image in new tab/window" >}} + {{< figure src="../resources/cdl-bpmn-agreement-process-decision1.png" width="1000" title="Click to zoom image in new tab/window" >}} You can see how the sequence flow (solid lines) picks up from Propose Deal action on the Seller's swimlane, even though the Buyer initiated the transaction. This is an example of how the Corda transaction guaranteed duplication in a counterparties vault can initiate that counterparty to take the next step in the overall business process. diff --git a/content/en/tools/cdl/bpmn-view/pools-and-swimlanes.md b/content/en/tools/cdl/bpmn-view/pools-and-swimlanes.md index a79e0aac67d..badcb07f080 100644 --- a/content/en/tools/cdl/bpmn-view/pools-and-swimlanes.md +++ b/content/en/tools/cdl/bpmn-view/pools-and-swimlanes.md @@ -16,4 +16,4 @@ Pools and swimlanes are standard features of BPMN. Usually a pool represents all Within the pool there is a swimlane for each participant that will contain their actions. -{{< figure zoom="../resources/cdl-bpmn-agreement-process-pools-and-swimlanes.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-bpmn-agreement-process-pools-and-swimlanes.png" width="1000" title="Click to zoom image in new tab/window" >}} diff --git a/content/en/tools/cdl/bpmn-view/starting-and-sequencing.md b/content/en/tools/cdl/bpmn-view/starting-and-sequencing.md index 841fe7d1788..e20a4e780a1 100644 --- a/content/en/tools/cdl/bpmn-view/starting-and-sequencing.md +++ b/content/en/tools/cdl/bpmn-view/starting-and-sequencing.md @@ -16,6 +16,6 @@ The start of a BPMN process is represented with a thin circle, normally annotate Activities or task are shown as Boxes within the swimlane of the participant who is performing the task. Sequential activities are shown by joining them with a solid line. -{{< figure zoom="../resources/cdl-bpmn-agreement-process-starting-and-sequencing.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-bpmn-agreement-process-starting-and-sequencing.png" width="1000" title="Click to zoom image in new tab/window" >}} So in this example, the process is started by the Buyer and the first thing they do is to *Decide what they would like to buy*. diff --git a/content/en/tools/cdl/cdl-overview.md b/content/en/tools/cdl/cdl-overview.md index 1e1bf81f211..c73b204847e 100644 --- a/content/en/tools/cdl/cdl-overview.md +++ b/content/en/tools/cdl/cdl-overview.md @@ -55,7 +55,7 @@ In earlier versions of CDL, the Smart Contract view was known as the State Machi #### An example Smart Contract view: -{{< figure zoom="./resources/cdl-agreement-smart-contract-full.png" width="800" title="Click to zoom image in new tab/window" >}} +{{< figure src="./resources/cdl-agreement-smart-contract-full.png" width="800" title="Click to zoom image in new tab/window" >}} This diagram shows the three statuses an agreement can have, together with the possible transitions from one status to another, and the constraints governing both statuses and transitions. @@ -88,7 +88,7 @@ You can't show the whole Corda Ledger in a single view (and wouldn't be useful t An example Ledger Evolution view: -{{< figure zoom="./resources/cdl-agreement-naive-billing-ledger-evolution-charlie.png" width="800" title="Click to zoom image in new tab/window" >}} +{{< figure src="./resources/cdl-agreement-naive-billing-ledger-evolution-charlie.png" width="800" title="Click to zoom image in new tab/window" >}} Here both states and transactions are represented as "nodes" in the graph. There is a connecting arrow from a transaction to a state when the state is an output of the transaction, and from a state to a transaction when the state is consumed by that transaction. @@ -107,7 +107,7 @@ The Business Process Modelling Notation view is, as the name suggests, a BPMN di An example BPMN view: -{{< figure zoom="./resources/cdl-bpmn-simultaneous-action.png" width="750" title="Click to zoom image in new tab/window" >}} +{{< figure src="./resources/cdl-bpmn-simultaneous-action.png" width="750" title="Click to zoom image in new tab/window" >}} The notation follows BPMN v2 standards, with a few small additions: diff --git a/content/en/tools/cdl/cdl-to-code/keep-it-structured.md b/content/en/tools/cdl/cdl-to-code/keep-it-structured.md index 3c00dd55017..9647c21861a 100644 --- a/content/en/tools/cdl/cdl-to-code/keep-it-structured.md +++ b/content/en/tools/cdl/cdl-to-code/keep-it-structured.md @@ -14,13 +14,13 @@ title: Keep it structured The CDL Smart Contract view deliberately separates the design into a set of considerations either to do with data structures or constraints over those data structures. You can show this diagrammatically: -{{< figure zoom="../resources/cdl-to-code-smart-contract-to-concerns.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-to-code-smart-contract-to-concerns.png" width="1000" title="Click to zoom image in new tab/window" >}} To minimise the risks of making mistakes when implementing the smart contract, you should consider each of the considerations separately. Narrowing the focus can give you greater confidence that each consideration is implemented correctly. In the Agreement example, as implemented in the cdl-example CorDapp, the CDL considerations map to the following code structures: -{{< figure zoom="../resources/cdl-to-code-concerns-to-structures.png" width="650" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-to-code-concerns-to-structures.png" width="650" title="Click to zoom image in new tab/window" >}} You can see in this diagram that: diff --git a/content/en/tools/cdl/cdl-to-code/linearid-constraints.md b/content/en/tools/cdl/cdl-to-code/linearid-constraints.md index a4134fc5dd7..9fa60bc1920 100644 --- a/content/en/tools/cdl/cdl-to-code/linearid-constraints.md +++ b/content/en/tools/cdl/cdl-to-code/linearid-constraints.md @@ -23,7 +23,7 @@ After the pre-check, we need to identify the situations where it is appropriate From the diagram we can see that occurs for the Reject, Repropose and Agree commands: -{{< figure zoom="../resources/cdl-agreement-smart-contract-full.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-smart-contract-full.png" width="1000" title="Click to zoom image in new tab/window" >}} Hence, we will perform a switch (`when` in Kotlin) on the commands and apply the linear ID check for those commands. diff --git a/content/en/tools/cdl/cdl-to-code/states-and-statuses.md b/content/en/tools/cdl/cdl-to-code/states-and-statuses.md index be9daf31b53..0320875d48e 100644 --- a/content/en/tools/cdl/cdl-to-code/states-and-statuses.md +++ b/content/en/tools/cdl/cdl-to-code/states-and-statuses.md @@ -46,7 +46,7 @@ You can see that `status` is nullable because the intention is to represent no s These interfaces are used to define the `AgreementState` and the enum set of statuses based on the CDL status states: -{{< figure zoom="../resources/cdl-agreement-smart-contract-statuses.png" width="900" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-smart-contract-statuses.png" width="900" title="Click to zoom image in new tab/window" >}} AgreementState.kt: diff --git a/content/en/tools/cdl/cdl-to-code/verifyPath.md b/content/en/tools/cdl/cdl-to-code/verifyPath.md index a492c954af3..969ed9e9a35 100644 --- a/content/en/tools/cdl/cdl-to-code/verifyPath.md +++ b/content/en/tools/cdl/cdl-to-code/verifyPath.md @@ -17,15 +17,15 @@ In the previous section we described how the `verifyPathConstraints()` function This diagram shows an example of an implementation of `VerifyPath`: -{{< figure zoom="../resources/cdl-contractutils-verifypath-simple.png" width="800" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-contractutils-verifypath-simple.png" width="800" title="Click to zoom image in new tab/window" >}} From the `LedgerTransaction` you can establish the `Path` in the transaction, as well as the status of the Primary input state. From the status of the Primary input state you can establish the set of allowed `PathConstraints` for the status of that input state. The `verifyPath()` function then takes the Path and checks it against each `PathConstraint`. If it can find a `PathConstraint` which allows the transaction `Path` then it returns `true`, if not, it will return `false` which will cause the `verifyPathConstraints()` function to throw a verification error. Looking in detail, you can see the properties in `Path` and `PathConstraint` respectively, together with the checks that each `PathConstraint` property applies to its corresponding `Path` property: -{{< figure zoom="../resources/cdl-contractutils-verifypath-with-properties.png" width="800" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-contractutils-verifypath-with-properties.png" width="800" title="Click to zoom image in new tab/window" >}} Then, for the full description, you must add in the `additionalStates` checks in which each required `additionStatesConstraint` must be satisfied by at least one of the `additionalStates` in the transaction: -{{< figure zoom="../resources/cdl-contractutils-verifypath-full.png" width="800" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-contractutils-verifypath-full.png" width="800" title="Click to zoom image in new tab/window" >}} diff --git a/content/en/tools/cdl/ledger-evolution-view/cdl-ledger-evolution-view.md b/content/en/tools/cdl/ledger-evolution-view/cdl-ledger-evolution-view.md index a9105a779ba..4f65de088c3 100644 --- a/content/en/tools/cdl/ledger-evolution-view/cdl-ledger-evolution-view.md +++ b/content/en/tools/cdl/ledger-evolution-view/cdl-ledger-evolution-view.md @@ -16,4 +16,4 @@ The Ledger Evolution view shows a sequence of Ledger transactions involving the For example, a Ledger Evolution diagram for your Agreement example smart contract might look like this: -{{< figure zoom="../resources/cdl-agreement-ledger-evolution-full.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-ledger-evolution-full.png" width="1000" title="Click to zoom image in new tab/window" >}} diff --git a/content/en/tools/cdl/ledger-evolution-view/exiting-the-ledger.md b/content/en/tools/cdl/ledger-evolution-view/exiting-the-ledger.md index 8b92d0fe35d..5fb193a5ef5 100644 --- a/content/en/tools/cdl/ledger-evolution-view/exiting-the-ledger.md +++ b/content/en/tools/cdl/ledger-evolution-view/exiting-the-ledger.md @@ -15,6 +15,6 @@ title: Exiting the ledger The example is nearly complete, we need the final transaction created and signed by Bob to remove the **AGREED** state from the Ledger using a Complete command. -{{< figure zoom="../resources/cdl-agreement-ledger-evolution-tx5.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-ledger-evolution-tx5.png" width="1000" title="Click to zoom image in new tab/window" >}} Hopefully this worked example has shown how the Ledger Evolution diagrams are a great way of bringing a smart contract to life by telling the 'story' of how it gets used in action. diff --git a/content/en/tools/cdl/ledger-evolution-view/input-states.md b/content/en/tools/cdl/ledger-evolution-view/input-states.md index e7bfbe4efb0..c3e4c6903a6 100644 --- a/content/en/tools/cdl/ledger-evolution-view/input-states.md +++ b/content/en/tools/cdl/ledger-evolution-view/input-states.md @@ -14,10 +14,10 @@ title: Input states Transaction input states are shown at the beginning of an arrow going into transaction boxes. You must ensure that an individual instance of a state is only ever shown once on the diagram, with input and output arrows linking it respectively to the transaction that created it, and the transaction that consumes it. -{{< figure zoom="../resources/cdl-agreement-ledger-evolution-tx2.png" width="900" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-ledger-evolution-tx2.png" width="900" title="Click to zoom image in new tab/window" >}} In this example, you can see that Bob has rejected Alice's proposal. He does this by creating and signing a transaction which consumes the **PROPOSED** state and creates a **REJECTED** state that: rejects the transaction because he has *Run out of bananas*. Continuing with the example, you can see that Bob has come up with a counter-proposal for *One bag of grapes* for £8. You can see that now Bob is the proposer, whereas Alice is the consenter in the new **PROPOSED** state and that he got to the **PROPOSED** state from a repropose command rather than a propose command. -{{< figure zoom="../resources/cdl-agreement-ledger-evolution-tx3.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-ledger-evolution-tx3.png" width="1000" title="Click to zoom image in new tab/window" >}} diff --git a/content/en/tools/cdl/ledger-evolution-view/interacting-with-other-smart-contracts.md b/content/en/tools/cdl/ledger-evolution-view/interacting-with-other-smart-contracts.md index 2d4522b6f06..40bc7a59421 100644 --- a/content/en/tools/cdl/ledger-evolution-view/interacting-with-other-smart-contracts.md +++ b/content/en/tools/cdl/ledger-evolution-view/interacting-with-other-smart-contracts.md @@ -17,6 +17,6 @@ Sometimes multiple smart contracts interact with each other in a single transact In the Agreement example, Alice now wants to accept Bob's proposal, however, the Agreement Smart Contract specifies that upon the Agree Command, there must also be a BillingChip owned by the seller in the transaction. Assume that a BillingChip is part of a separate Smart Contract which provides a mechanism for tracking cumulative usage on the network. -{{< figure zoom="../resources/cdl-agreement-ledger-evolution-tx4-b.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-ledger-evolution-tx4-b.png" width="1000" title="Click to zoom image in new tab/window" >}} The BillingChip is greyed out to show it as different to the Agreement Primary state, although this is optional. diff --git a/content/en/tools/cdl/ledger-evolution-view/modelling-the-ledger.md b/content/en/tools/cdl/ledger-evolution-view/modelling-the-ledger.md index 0e87a68b080..b6bb23f48e3 100644 --- a/content/en/tools/cdl/ledger-evolution-view/modelling-the-ledger.md +++ b/content/en/tools/cdl/ledger-evolution-view/modelling-the-ledger.md @@ -21,7 +21,7 @@ The Corda Ledger can be considered as a Directed Acyclic Graph (DAG) in which: You could illustrate this as follows: -{{< figure zoom="../resources/cdl-ledger-dag.png" width="800" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-ledger-dag.png" width="800" title="Click to zoom image in new tab/window" >}} However, it is difficult to get all the information you may want to show into this format. To convey more information, you can use a similar form but modify the graph's nodes to align more closely to the representations of states already introduced in the Smart Contract view. diff --git a/content/en/tools/cdl/ledger-evolution-view/output-states.md b/content/en/tools/cdl/ledger-evolution-view/output-states.md index 983838401a3..7f313d9fcb9 100644 --- a/content/en/tools/cdl/ledger-evolution-view/output-states.md +++ b/content/en/tools/cdl/ledger-evolution-view/output-states.md @@ -14,7 +14,7 @@ title: Output states Transaction output states take a similar form to the Smart Contract view and are shown at the end of an arrow coming out of the transaction: -{{< figure zoom="../resources/cdl-agreement-ledger-evolution-tx1.png" width="500" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-ledger-evolution-tx1.png" width="500" title="Click to zoom image in new tab/window" >}} You can see that whereas in the Smart Contract view the state boxes show the property types, in the Ledger Evolution view the state boxes show actual values for the properties. diff --git a/content/en/tools/cdl/ledger-evolution-view/reference-states.md b/content/en/tools/cdl/ledger-evolution-view/reference-states.md index fb3f0340784..93fc7a5fc3e 100644 --- a/content/en/tools/cdl/ledger-evolution-view/reference-states.md +++ b/content/en/tools/cdl/ledger-evolution-view/reference-states.md @@ -18,4 +18,4 @@ You can show reference states as input states but with a dashed line from the st In the Agreement example, the Smart Contract requires that the BillingChip value is the same as the value specified by a ratecard state. This rate card needs to be used in multiple transactions so it is included as a reference state: -{{< figure zoom="../resources/cdl-agreement-ledger-evolution-tx4-c.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-ledger-evolution-tx4-c.png" width="1000" title="Click to zoom image in new tab/window" >}} diff --git a/content/en/tools/cdl/ledger-evolution-view/transactions-commands-signers.md b/content/en/tools/cdl/ledger-evolution-view/transactions-commands-signers.md index 4731956311d..b3f378813a7 100644 --- a/content/en/tools/cdl/ledger-evolution-view/transactions-commands-signers.md +++ b/content/en/tools/cdl/ledger-evolution-view/transactions-commands-signers.md @@ -18,9 +18,9 @@ You can represent a transaction as a layered box. In this example: - The middle green box is the command for the Primary state. - The bottom box contains the actual signers of the transaction. -{{< figure zoom="../resources/cdl-agreement-ledger-evolution-tx1-a.png" width="250" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-ledger-evolution-tx1-a.png" width="250" title="Click to zoom image in new tab/window" >}} If a transaction has additional commands relating to other Smart Contract operating in the transaction, then these are added as extra middle boxes: -{{< figure zoom="../resources/cdl-agreement-ledger-evolution-tx4-a.png" width="250" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-ledger-evolution-tx4-a.png" width="250" title="Click to zoom image in new tab/window" >}} diff --git a/content/en/tools/cdl/privacy-overlay/adding-the-privacy-overlay.md b/content/en/tools/cdl/privacy-overlay/adding-the-privacy-overlay.md index 3cb135ce60f..5c892ab5f00 100644 --- a/content/en/tools/cdl/privacy-overlay/adding-the-privacy-overlay.md +++ b/content/en/tools/cdl/privacy-overlay/adding-the-privacy-overlay.md @@ -20,10 +20,10 @@ If a transaction contains information the Party is allowed to see, you mark the In this diagram, these visibility permissions are illustrated by AgreeCorp who, per the requirements, is not allowed to see any Agreements on its network: -{{< figure zoom="../resources/cdl-agreement-naive-billing-ledger-evolution-agreecorp.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-naive-billing-ledger-evolution-agreecorp.png" width="1000" title="Click to zoom image in new tab/window" >}} This is extended to Charlie, who is permitted to see his own Agreement, but not prior Agreements in the backchain: -{{< figure zoom="../resources/cdl-agreement-naive-billing-ledger-evolution-charlie.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-naive-billing-ledger-evolution-charlie.png" width="1000" title="Click to zoom image in new tab/window" >}} You can see from this view that the initial mechanism for implementing Billing creates privacy leaks in transaction tx 4b and in the backchain. It is clear that this design requires a better mechanism. diff --git a/content/en/tools/cdl/privacy-overlay/billing-example.md b/content/en/tools/cdl/privacy-overlay/billing-example.md index ccda70a7015..ab222a1f663 100644 --- a/content/en/tools/cdl/privacy-overlay/billing-example.md +++ b/content/en/tools/cdl/privacy-overlay/billing-example.md @@ -26,20 +26,20 @@ The requirements for the Billing mechanism are: The intuitive approach to meeting these requirements is to create a BillingState which that must be included in each Agree transaction, with a cumulativeUse tracker that increments by a per transaction rate each time it is used. The Smart Contract for this BillingState might look like this: -{{< figure zoom="../resources/cdl-naive-billing-smart-contract.png" width="700" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-naive-billing-smart-contract.png" width="700" title="Click to zoom image in new tab/window" >}} With a corresponding RateCard smart contract: -{{< figure zoom="../resources/cdl-ratecard-smart-contract.png" width="700" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-ratecard-smart-contract.png" width="700" title="Click to zoom image in new tab/window" >}} You can show the Billing and RateCard Smart Contracts interacting with the Agreement Smart Contract using the Ledger Evolution view: -{{< figure zoom="../resources/cdl-agreement-naive-billing-ledger-evolution-tx4-a.png" width="700" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-naive-billing-ledger-evolution-tx4-a.png" width="700" title="Click to zoom image in new tab/window" >}} You can see that the cumulativeUse property has increased between the input.BillingState and output.BillingState by the amount indicated in the RateCardState. You can then show what happens when the same billing token is used in another Agree transaction, this time with Charlie to buy 'One kg of sausages' for £20: -{{< figure zoom="../resources/cdl-agreement-naive-billing-ledger-evolution-tx4-b.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-naive-billing-ledger-evolution-tx4-b.png" width="1000" title="Click to zoom image in new tab/window" >}} The next step is to add the privacy overlay. diff --git a/content/en/tools/cdl/privacy-overlay/private-billing.md b/content/en/tools/cdl/privacy-overlay/private-billing.md index 55fbed7bee8..2d0910ad71d 100644 --- a/content/en/tools/cdl/privacy-overlay/private-billing.md +++ b/content/en/tools/cdl/privacy-overlay/private-billing.md @@ -22,22 +22,22 @@ In the private Billing mechanism in the Agreement example, the dependent state i The Billing Smart Contract now looks like this diagram. You can see that there is the additional BillingChip state as well as the Primary BillingState: -{{< figure zoom="../resources/cdl-private-billing-smart-contract.png" width="700" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-private-billing-smart-contract.png" width="700" title="Click to zoom image in new tab/window" >}} In the Ledger Evolution view, the generation of the BillingChip is shown as follows: -{{< figure zoom="../resources/cdl-agreement-private-billing-ledger-evolution-chip1.png" width="700" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-private-billing-ledger-evolution-chip1.png" width="700" title="Click to zoom image in new tab/window" >}} The BillingChip can then go on to be used as the enabler for the dependent Agree transaction: -{{< figure zoom="../resources/cdl-agreement-private-billing-ledger-evolution-tx4-a.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-private-billing-ledger-evolution-tx4-a.png" width="1000" title="Click to zoom image in new tab/window" >}} Then the same steps are repeated for Charlie's sausage transaction (Tx 4b): -{{< figure zoom="../resources/cdl-agreement-private-billing-ledger-evolution-tx4-b.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-private-billing-ledger-evolution-tx4-b.png" width="1000" title="Click to zoom image in new tab/window" >}} Now you can add the Privacy Overlays for AgreeCorp and Charlie we see that privacy has been preserved: -{{< figure zoom="../resources/cdl-agreement-private-billing-ledger-evolution-privacy-overlays.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-private-billing-ledger-evolution-privacy-overlays.png" width="1000" title="Click to zoom image in new tab/window" >}} Explicitly, AgreeCorp's node doesn't resolve either Tx 4a or Tx 4b and Charlies node doesn't resolve the previous agreement between Alice and Bob. diff --git a/content/en/tools/cdl/smart-contract-view/building-the-smart-contract-view.md b/content/en/tools/cdl/smart-contract-view/building-the-smart-contract-view.md index 7e5facd4edf..f06e0708a38 100644 --- a/content/en/tools/cdl/smart-contract-view/building-the-smart-contract-view.md +++ b/content/en/tools/cdl/smart-contract-view/building-the-smart-contract-view.md @@ -28,4 +28,4 @@ You will follow a simple negotiation use case, where a buyer is negotiating to b You can follow the steps in the build up to a full Smart Contract view diagram which, will look like this: -{{< figure zoom="../resources/cdl-agreement-smart-contract-full.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-smart-contract-full.png" width="1000" title="Click to zoom image in new tab/window" >}} diff --git a/content/en/tools/cdl/smart-contract-view/cdl-smart-contract-view.md b/content/en/tools/cdl/smart-contract-view/cdl-smart-contract-view.md index ca36b118da8..a94ffbd68bf 100644 --- a/content/en/tools/cdl/smart-contract-view/cdl-smart-contract-view.md +++ b/content/en/tools/cdl/smart-contract-view/cdl-smart-contract-view.md @@ -15,4 +15,4 @@ title: Smart Contract View In this section you can learn about the CDL Smart Contract view. You will see what is meant by a Corda smart contract, how the Smart Contract view adds structure to your CorDapp designs, and use an example use case to build up to the following full Smart Contract view diagram: -{{< figure zoom="../resources/cdl-agreement-smart-contract-full.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-smart-contract-full.png" width="1000" title="Click to zoom image in new tab/window" >}} diff --git a/content/en/tools/cdl/smart-contract-view/command-constraints.md b/content/en/tools/cdl/smart-contract-view/command-constraints.md index d52d60ff166..626494e203c 100644 --- a/content/en/tools/cdl/smart-contract-view/command-constraints.md +++ b/content/en/tools/cdl/smart-contract-view/command-constraints.md @@ -15,7 +15,7 @@ title: Command constraints The final type of constraint to add to the Smart Contract view is the Command constraint. Command constraints are constraints which apply when a particular Command is used in the transaction. They can place constraints on any part of the transaction, including on states which are not part of this Smart Contract. -{{< figure zoom="../resources/cdl-agreement-smart-contract-command-constraints.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-smart-contract-command-constraints.png" width="1000" title="Click to zoom image in new tab/window" >}} You can use Command constraints to indicate, amongst other things: diff --git a/content/en/tools/cdl/smart-contract-view/flow-constraints.md b/content/en/tools/cdl/smart-contract-view/flow-constraints.md index bdde5744083..0b0aa6eafd4 100644 --- a/content/en/tools/cdl/smart-contract-view/flow-constraints.md +++ b/content/en/tools/cdl/smart-contract-view/flow-constraints.md @@ -17,7 +17,7 @@ Each of the transitions shown in a Smart Contract view diagram are enacted throu Flow constraints are denoted by a blue box attached to the relevant Path: -{{< figure zoom="../resources/cdl-agreement-smart-contract-flow-constraints.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-smart-contract-flow-constraints.png" width="1000" title="Click to zoom image in new tab/window" >}} {{< attention >}} Flow constraints are ***not*** implemented in the smart contract, they are really only a note about what a different part of the CorDapp *may* be doing when a Path is enacted. As they are not implemented in the smart contract they don't carry the same Corda guarantees that different counterparties are following the same set of rules. Or to put it another way, the counterparty could have re-written their Flows: don't place critical business controls that other parties will rely on in the Flows. diff --git a/content/en/tools/cdl/smart-contract-view/modelling-using-statuses.md b/content/en/tools/cdl/smart-contract-view/modelling-using-statuses.md index 9b32dd0ba26..26e29c6c61d 100644 --- a/content/en/tools/cdl/smart-contract-view/modelling-using-statuses.md +++ b/content/en/tools/cdl/smart-contract-view/modelling-using-statuses.md @@ -24,7 +24,7 @@ For simple Smart Contracts there may only be one, implicit status. The Smart Con For example, you may wish to represent a smart contract made up of a `CashState` and `CashContract` using a single status: - {{< figure zoom="../resources/../resources/cdl-overview-cashstate.png" width="750" title="Click to zoom image in new tab/window" >}} + {{< figure src="../resources/../resources/cdl-overview-cashstate.png" width="750" title="Click to zoom image in new tab/window" >}} This shows a `CashState` with its properties and participants. It then shows the various constraints imposed on that `CashState` by the `CashContract`, specifically: diff --git a/content/en/tools/cdl/smart-contract-view/mulitiplicities.md b/content/en/tools/cdl/smart-contract-view/mulitiplicities.md index 9890ce8df9f..f1cd9faf64f 100644 --- a/content/en/tools/cdl/smart-contract-view/mulitiplicities.md +++ b/content/en/tools/cdl/smart-contract-view/mulitiplicities.md @@ -36,10 +36,10 @@ For example, in the diagram below, Path 1 'PROPOSED -- Agree --> AGREED': * The input multiplicity is 1, indicating there must be one and only one input state of type AgreementState in status 'PROPOSED' * The output multiplicity is 1: Matched, indicating there must be one and only one output state of type AgreementState and that the LinearID must match that of the input state. -{{< figure zoom="../resources/cdl-agreement-smart-contract-paths.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-smart-contract-paths.png" width="1000" title="Click to zoom image in new tab/window" >}} Where the Path starts or ends at a black circle, the implied Multiplicity = 0..0 The following example of a CashState shows how multiplicities can be expressed as ranges: -{{< figure zoom="../resources/cdl-overview-cashstate.png" width="700" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-overview-cashstate.png" width="700" title="Click to zoom image in new tab/window" >}} diff --git a/content/en/tools/cdl/smart-contract-view/path-constraints.md b/content/en/tools/cdl/smart-contract-view/path-constraints.md index 9ffaa7780b4..96349b9040e 100644 --- a/content/en/tools/cdl/smart-contract-view/path-constraints.md +++ b/content/en/tools/cdl/smart-contract-view/path-constraints.md @@ -36,7 +36,7 @@ Path constraints are shown on the diagram as arrows between state statuses, the * Path 1: 'PROPOSED -- Agree --> AGREED' * Path 2: 'PROPOSED -- Reject --> REJECTED' -{{< figure zoom="../resources/cdl-agreement-smart-contract-paths.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-smart-contract-paths.png" width="1000" title="Click to zoom image in new tab/window" >}} A black circle indicates no state, hence an arrow coming out of a black circle means there can be no inputs of the primary state type in the transaction. An arrow going into a black circle means there are no outputs of the primary state type in the transaction. diff --git a/content/en/tools/cdl/smart-contract-view/signing-constraints.md b/content/en/tools/cdl/smart-contract-view/signing-constraints.md index 0155814b7b8..eba3c915fc1 100644 --- a/content/en/tools/cdl/smart-contract-view/signing-constraints.md +++ b/content/en/tools/cdl/smart-contract-view/signing-constraints.md @@ -14,7 +14,7 @@ title: Signing constraints An important aspect of any CorDapp is the permissioning model, in other words who needs to sign which transactions. In Corda, the required signers are attached to the transaction's Command. This can be mirrored in the CDL Smart Contract view by including the require signer in brackets underneath the Command on the Path constraint. -{{< figure zoom="../resources/cdl-agreement-smart-contract-signing.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-smart-contract-signing.png" width="1000" title="Click to zoom image in new tab/window" >}} The signer is usually defined in terms of some property in the State. You would not usually specify that a particular Party, say PartyA must sign, instead you would specify that the party referenced in the seller property needs to sign, which may on some instances of the state happen to be PartyA. diff --git a/content/en/tools/cdl/smart-contract-view/states.md b/content/en/tools/cdl/smart-contract-view/states.md index d318c6001d5..3782030471c 100644 --- a/content/en/tools/cdl/smart-contract-view/states.md +++ b/content/en/tools/cdl/smart-contract-view/states.md @@ -18,7 +18,7 @@ The first element of the diagram to consider is the Primary state type, in this * **Properties**: Contains the properties in the state class together with their classes. * **Participants**: Contains the participants - the Parties that will get a copy of any transaction in which this state is included as an input or output (but not reference state). -{{< figure zoom="../resources/cdl-agreement-smart-contract-state.png" width="350" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-smart-contract-state.png" width="350" title="Click to zoom image in new tab/window" >}} In the Agreement example use case, the following properties are required: diff --git a/content/en/tools/cdl/smart-contract-view/status-constraints.md b/content/en/tools/cdl/smart-contract-view/status-constraints.md index d117bf3dfde..ddc75faf938 100644 --- a/content/en/tools/cdl/smart-contract-view/status-constraints.md +++ b/content/en/tools/cdl/smart-contract-view/status-constraints.md @@ -17,7 +17,7 @@ Status constraints are constraints over the Primary state when it is a particula They are shown as a rounded box under the status state box to which the constraints apply: -{{< figure zoom="../resources/cdl-agreement-smart-contract-status-constraints.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-smart-contract-status-constraints.png" width="1000" title="Click to zoom image in new tab/window" >}} In the Agreement example use case, status constraints are used to show which state properties must be populated for a particular status. In particular, the aim is to: diff --git a/content/en/tools/cdl/smart-contract-view/statuses.md b/content/en/tools/cdl/smart-contract-view/statuses.md index 72f0b15666a..caff865dc14 100644 --- a/content/en/tools/cdl/smart-contract-view/statuses.md +++ b/content/en/tools/cdl/smart-contract-view/statuses.md @@ -15,7 +15,7 @@ title: Statuses Once you have defined the state, you need to show the different statuses that the state can be in. You do this by having a copy of the State for each status. -{{< figure zoom="../resources/cdl-agreement-smart-contract-statuses.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-smart-contract-statuses.png" width="1000" title="Click to zoom image in new tab/window" >}} The properties shown in each status box may differ. This allows you to highlight the properties which are salient for that status even though they are actually a view of the same underlying class which must implement the union of all properties on the diagram. diff --git a/content/en/tools/cdl/smart-contract-view/universal-constraint.md b/content/en/tools/cdl/smart-contract-view/universal-constraint.md index b8cbf5866e8..02360608d12 100644 --- a/content/en/tools/cdl/smart-contract-view/universal-constraint.md +++ b/content/en/tools/cdl/smart-contract-view/universal-constraint.md @@ -16,6 +16,6 @@ Universal constraints are constraints over the Primary state which must be satis They are shown as a rounded box in the top left corner of the diagram: -{{< figure zoom="../resources/cdl-agreement-smart-contract-universal.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-smart-contract-universal.png" width="1000" title="Click to zoom image in new tab/window" >}} In our use case we want to make sure that the buyer and seller are different parties, and that it is only the buyer and seller that are proposing and consenting to agreements. diff --git a/content/en/tools/cdl/testing/cdl-testing.md b/content/en/tools/cdl/testing/cdl-testing.md index 6a6b74ee700..8e26bad169c 100644 --- a/content/en/tools/cdl/testing/cdl-testing.md +++ b/content/en/tools/cdl/testing/cdl-testing.md @@ -14,7 +14,7 @@ title: Testing CDL code To test CDL Code we want to maintain and extend the structure we used to map the CDL considerations to the implemented code. We can show this diagrammatically: -{{< figure zoom="../resources/cdl-to-code-testing.png" width="800" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-to-code-testing.png" width="800" title="Click to zoom image in new tab/window" >}} The ContractUtils has its own extensive testing, which can be seen in the [cdl-example](https://github.com/corda/cdl-example) `ContractUtilsTests.kt` diff --git a/content/en/tools/cdl/testing/happy-path.md b/content/en/tools/cdl/testing/happy-path.md index 07d336fb1f4..70a7b2754b8 100644 --- a/content/en/tools/cdl/testing/happy-path.md +++ b/content/en/tools/cdl/testing/happy-path.md @@ -14,7 +14,7 @@ title: Happy path To test the happy path we are going to use the same sequence of transactions as shown in the Ledger Evolution diagram we saw earlier: -{{< figure zoom="../resources/cdl-agreement-ledger-evolution-tx5.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-agreement-ledger-evolution-tx5.png" width="1000" title="Click to zoom image in new tab/window" >}} We will use the Corda MockNetwork DSL to generate a sequence of transactions representing the transactions in the diagram: diff --git a/content/en/tools/cdl/testing/non-happy-path.md b/content/en/tools/cdl/testing/non-happy-path.md index 7f99c122ab4..0e3a28c1bc0 100644 --- a/content/en/tools/cdl/testing/non-happy-path.md +++ b/content/en/tools/cdl/testing/non-happy-path.md @@ -18,7 +18,7 @@ At the end of the testing we want to have confidence we have covered all of the The approach used in the cdl-example builds up a layered tree structure: -{{< figure zoom="../resources/cdl-testing-structure.png" width="1000" title="Click to zoom image in new tab/window" >}} +{{< figure src="../resources/cdl-testing-structure.png" width="1000" title="Click to zoom image in new tab/window" >}} We take each constraint in turn, for each constraint we take each of the predicates that drives the constraint's behaviour, then for each predicate value we identify a potential error type, then for each error type the error value. diff --git a/themes/doks/layouts/shortcodes/figure.html b/themes/doks/layouts/shortcodes/figure.html index 8a69cf4890b..4146588f9d7 100644 --- a/themes/doks/layouts/shortcodes/figure.html +++ b/themes/doks/layouts/shortcodes/figure.html @@ -1,64 +1,96 @@ -{{/* initialize image variables */}} +{{/* +----------------------------------------------- +FIGURE SHORTCODE — WHAT THIS DOES +----------------------------------------------- +This shortcode inserts an image (
and ) with optional +caption, title, alt text, width, height, and alignment attributes. + +It automatically searches for the image in several locations in order: + 1. Inside the current page bundle (.Page.Resources) + 2. In Hugo’s assets/images/ + 3. In the static folder + 4. In the same folder as the current page file + 5. In a "resources" subfolder beside the page + +For bundle pages (those with index.md or _index.md): + - If an image path uses "../" to go outside the bundle folder, + the build will FAIL with an error message. + - This ensures all bundle images stay self-contained. + +For standalone markdown files (non-bundles): + - "../" paths are allowed, e.g. "../resources/my-image.png". + +If no valid image can be found in any of the locations, + the build FAILS with a clear error message showing + the missing image path and the markdown file’s location. + +In summary: + ✔ Works for both bundle and non-bundle pages + ✔ Supports named or positional parameters + ✔ Fails loudly when an image cannot be displayed + ✔ Keeps image references safe and predictable +----------------------------------------------- +*/}} + {{ $src := "" }} -{{ $zoom := "" }} {{ $figcaption := "" }} {{ $alt := "" }} {{ $title := "" }} {{ $width := "" }} {{ $height := "" }} {{ $align := "" }} -{{/* set image variables if passed as named params */}} + {{ if .IsNamedParams }} {{ $src = .Get "src" }} - {{ $zoom = .Get "zoom" }} {{ $figcaption = .Get "figcaption" }} {{ $alt = .Get "alt" }} {{ $title = .Get "title" }} {{ $width = .Get "width" }} {{ $height = .Get "height" }} {{ $align = .Get "align" }} - {{if not $src}} - {{$src = $zoom }} - {{end}} -{{/* assume src is first param and alt is second if params not named */}} {{ else }} {{ $src = .Get 0 }} {{ $alt = .Get 1 }} -{{end}} -{{/* retrieve image file if part of page resources */}} -{{ $image := .Page.Resources.GetMatch (printf "*%s*" $src ) -}} -{{/* retrieve image file if in assets\images\ - used if figure is called from a snippet */}} -{{/* Figure out what folder in corda-docs-portal\themes\doks\assets\images to look in based on version of the page calling the shortcode */}} +{{ end }} + +{{ $image := .Page.Resources.GetMatch (path.Base $src) }} {{ $versionfolder := replace (lower (.Page.Params.version)) " " "-" }} {{ $path := printf "%s" $src | printf "%s%s" "/" | printf "%s%s" $versionfolder | printf "%s%s" "images/" | printf "%s" }} -{{ $assetimage := resources.Get (printf "%s" $path ) -}} +{{ $assetimage := resources.Get (printf "%s" $path ) }} +
- {{if $zoom}}{{end}} - {{$alt}} - {{if $figcaption }}
{{$figcaption}}
{{end}} - {{if $zoom}}{{end}} -
\ No newline at end of file + alt="{{ $alt }}" + {{ if $title }} title="{{ $title }}"{{ end }} + {{ if $width }} width="{{ $width }}"{{ end }} + {{ if $height }} height="{{ $height }}"{{ end }} + {{ if $align }} align="{{ $align }}"{{ end }} + /> + {{ if $figcaption }}
{{ $figcaption }}
{{ end }} +