Any implementation of the Mesh APIs must connect exclusively to a running blockchain node in the same Dockerfile. It is not ok to connect to some external service that preprocesses blockchain data or to a blockchain node running elsewhere.
Populating Operation.Amount with Balance instead of Balance Changes
Some blockchains prefer to surface balance changes by returning the balance of an account after an operation is applied instead of returning how much an operation changes an account’s balance.
In Mesh, the Operation.Amount.Value field should always be populated with the balance change (or “delta”), not the new balance of an account after an operation is applied (sometimes called “state streaming”).
If you would still like to surface the balance of an account after an operation is applied because it is expected by users of the blockchain you are implementing, you should add it to the Operation.Metadata field (along with any other useful metadata you want to return). It is not required to surface the balance of an account after an operation is applied.
Correct Example: Operation Amount is Balance Change
In the following example, account A and account B each have 100 CURR prior to the transaction. In the transaction, A transfers 50 CURR to B.
In this example, Operation.Amount.Value is populated with the balance change of each account involved in the transaction instead of the new balance of each account involved in the transaction. The new balance of each account involved in the transaction is added to Operation.Metadata (optional).
In 2017, the OpenAPI Initiative published the OpenAPI 3.0 standard as a successor to the Swagger Specification. The Swagger Specification was then renamed to OpenAPI 2.0.
Not all tools developed for Swagger/OpenAPI 2.0 are compatible with this OpenAPI 3.0 format. Be sure to double check that any code you utilize to power your implementation is compatible.
When populating the genesis block, it may be unclear which index and hash to use in the ParentBlockIdentifier. It is recommended to use the genesis BlockIdentifier for both block_identifier and parent_block_identifier.
Return Transactions to Fetch in Block Transactions
If transactions must be retrieved using the /block/transaction endpoint, they must be returned in other_transactions. Recall, this endpoint is used when the /block endpoint does not populate all transactions (it is optional).
The /construction/submit endpoint must only return a 200 status if the submitted transaction could be included in the mempool. If a submission could not be included (ex: invalid signature), it must return an error.
Any request to the /construction/submit endpoint must not block on the transaction being included in a block. It must return immediately with an indication of whether or not the transaction was included in the mempool. Handling transaction rebroadcast is a requirement placed on the client.
Any AccountIdentifier returned in a block could be used as an input to an /account/balance request. Ensure your Mesh Server can gracefully handle any request containing an AccountIdentifier found in a block.
Populating Amount without Populating Account in an Operation
In Mesh, all operations that contain an amount must also contain a populated account (that can be retrieved using the /account/balance endpoint). “Dangling” balance changes (unattributable balance changes) can create insurmountable data or auditing challenges for some institutional blockchain users, which could prevent them from integrating with your implementation.
It is important to note that this does not mean that every operation with a populated account must have an amount. In fact, this is allowed and is a popular pattern to represent on-chain activity that does not involve a balance change (where operation metadata is populated with on-chain data).
Mesh uses signed operation amounts. Any account balance decrease must be represented by a negative amount and any balance increase must be represented by a positive amount. Because of this design decision, users of the Mesh API do not need to parse network-specific types to understand how to interpret an amount.
Transactions in some blockchains are executed (i.e. change state) after the block they were included in (instead of in the block). In other words, each transaction in block N is applied by block N + 1 instead of in N. In Mesh, transactions must be included in the block in which they are executed (regardless of when they are first included in a block).
If this applies to your implementation, it is highly recommended to indicate where the transaction first appeared in the transaction metadata: