Blockchain2Blochain interaction

The problem

The core contains all the accounts, their public keys and multisignature settings. Accordingly, all other services for transaction validation must access the core to obtain this data. They cannot be cached since the multisignature data can change at any moment.

This interaction significantly affects the processing speed of transactions.

Solutions

1. Make interaction over the network direct.

   1. Significantly reduces performance.

2. Run the core and other processes in the same address space.

   1. Extremely difficult to execute. Requires additional tendermint execution for the core and strict testing to ensure things dont gets mixed up.

   2. High resource consumption.

3. Duplicate core data in secondary services.

   1. Makes interaction mechanism more complicated.

   2. The API and communication protocol is not clear. Tendermint assumes that all requests go through the query method.

   3. Difficulty with reading the genesis condition (since it is not formed as a block).

   4. Possible pull/push interaction model.

4. Removing the EDS verification from the peer to the intermediate layer.

   1. Only suitable for a fully closed network.

   2. Very scalable.

   3. Makes it possible to conduct "side" transactions if you slip in after the intermediate layer.

      • Protective options:

      • Authorization on the tendermint-port via an HTTPS key.

      • Additional EDS added by the intermediate layer and validated on the peer.

   4. A full-fledged parsing of processed commands is required to identify signers and verify all mentioned accounts.

In general, options (1/2/3) can be combined at API level and differ in implementation. Option (4) can be implemented by substituting IEdsChecker and by an intermediate service.

Network interaction

Tendermint is single-threaded by nature, which leads to significant performance drops in network communication.

In general, there are multiple ways to optimize the interaction, but they will not be able to speed up the peer's performance by tenfold.

This type of interaction is used now.

Unified address space

graph LR

    FrontC[CoreFront] -- HTTP --> TMC
    TMC(CoreTendermint) -- TSP --> App[Peer]

    bot --> TMC
    bot --> TMP

    FrontP[CoinFront] -- HTTP --> TMP
    TMP(CoinTendermint) -- TSP --> App

    App --> App

Pros:

• Extremely fast interaction within a single process.

• Possible to access historical core data.

• There is no need for complicated data caching mechanics.

Cons:

• Significantly complicates the peer launch.

• Significatly increases the hardware requirements.

• Requires disabling the plugin autodetection mechanism (because 2 peers within the same process have a different set of plugins).

Problem 1: Two peers have to work in sync

The payment peer requires information about the current block in the core. This data must arrive synchronously and inconsistently to all peers (with the flow of transactions to the payment peer).

• Sending a transaction with information about the current block to the payment peer.

  • Checking process:

    • The new block is newer than the previous data.

    • The block is present in the blockchain core.

  • If the block is not present in the blockchain core, the transaction is considered invalid.

    • Requires a study on how tendermint behaves if a block is once considered invalid - will it try to re-import the same block?

  • Given that in tendermint observers can lag behind generators (even individual generators can lag), the main question is what delay will the blockchain data in the core have when going into the payment blockchain.

• What happens when you re-import the history?

  • The block transaction in the core can have 3 states:

    • The core already has this type of a block locally.

      • The transaction is assured to be valid.

    • There is no block with this height locally.

      • To process unconfirmed data, consider the transaction invalid.

      • Waiting for certainty when the block is confirmed.

        • To shorten the wait time, it must be assumed that the transaction switches exclusively to the next block and not just any senior block. In the worst case, the payment network will wait for the checked block to appear in the core for a few seconds.

        • Alternatively, we could "fall down". But we doubt that's the answer. The network could go down.

    • There is a block of this height, but it is different.

      • The transaction is assured to be invalid.

Data duplication by keys and multi-signature

EDS verification export

Great option in terms of horizontal scaling. But to work properly, the commands of the target service should be parsed correctly.

There are plans to switch to this scenario in the long run.

Implementation

For this implementation it is proposed to make a module in the core. It will launch with a peer and have direct access to the necessary data and will validate EDS transactions. It will then forward them for confirmation to the peers of the tendermint payment network.

Pros:

• Direct access to account data, quick EDS verification.

Cons:

• It is necessary to keep track of the current snapshot and always look at the current data.

• Complicates the core and payment service peers.

• Requires parsing of the payment service transactions in the core as well.