Hey guys, I’m wondering how transactions get passed through the Vega application to Tendermint. This is the flow I’m wondering about:
Signed vega transaction is submitted to Vega node
Vega application checks validity of signature
Vega application makes state change based on submitted transaction
State change is represented as a Tendermint ABCI tx,
Tendermint ABCI transaction is signed by the Node’s Vega key and submitted through ABCI to the tendermint binary
Tendermint binary checks validity of signature, and propagates it through tendermint’s peer exchange
Specifically unclear around steps 3-6.
If it’s correct, I’m wondering if the Vega key in 5 needs to be one of the vega keys registered in genesis, or can be a non-validator vega node’s key.
Is that vega key that is registered in genesis needed for any state transition or verification, or is it simply the key for accounts to delegate to for staking?
Ok, so… there are only Vega txns, no ABCI or Tendermint transactions. ABCI is an interface which the Vega application uses to talk to the Tendermint blockchain (hence ABCI: Application Block Chain Interface). Tendermint talks to other nodes using the Tendermint consensus protocol to (a) share Vega txns it’s seen with them); and (b) “agree” an ordered list of Vega transactions that comprise the next block.
Signed Vega transaction (signed with Vega key) submitted to Vega node. Note that these are submitted to a Tendermint API not the Vega application (although in some cases Vega may provide helper APIs to construct and/or submit txns, this is a convenience and not required, you could consrtruct a valid tx yourself eassily enough and submit to Tendermint directly on the node).
Tendermint asks the Vega application to validate (check) the transaction using the ABCI CheckTx message. This does not process the transaction but it does alllow the application to do basic validity checks so bad/malformed txns can be rejected before they get sequenced into a block.
Tendermint does Tendermint consensus protocol stuff (txns gossiped between nodes, leader node proposes a block, nodes vote on block contents, consensus is reached, etc. etc.). This is not ABCI, it’s the Tendermint consensus protocol which uses something akin to the PBFT algorithm. The Tendermint key is used here by the node when it communicates using the consensus protocol with other nodes, to identify itself and verify it as the source of the communication. The txns being sent around and put in blocks are still Vega txns, signed with the same Vega key as at the start.
Tendermint asks the Vega application to process the Vega transaction and update the application state using the ABCI DeliverTx message.
The Vega application does the heavy lifting to process the transaction, and calculates an updated state root (merkle root of the applicaton state).
After the entire block is processed in this way, Tendermint asks the application for the new state root using the Commit message. This will be used in the header for the next block when it is proposed by the leader node. When this header is sent to all the other nodes, they will verify that the state root the leader sent matches what they have locallty from the Commit step. Therefore, if the state root is calculated properly from the complete state using a good hash function, all nodes have the exact same state.
As for your questions:
Your step 5 doesn’t exist. the txns are always Vega txns, always signed by the submitter’s Vega key. The Tendermint consensus protocol communications between nodes always use the node’s Tendermint key. ABCI is an interface not a set of transactions and is used for communication between Tendermint and the Vega application on the same node, so ABCI messages are not signed.
The node’s Vega key is used to sign Vega txns that need to be submitted by the Vega node itself. For example, the transactions each volidator node sends when it observes an event of interest on the Ethereum blockchain via the Ethereum Event Forwarder. It also identifies the node for staking and is the Vega key that staking rewards are paid to by the protocol.
That’s extremely helpful, thanks Barney I’ve had another look at the Tendermint docs now, and with your explanation have decoded them a bit more.
Is there a list of the transactions which a node’s Vega key is used for? Anything other than the ethereum event forwarder at the moment?
Since the gRPC endpoint is hitting port 3002, shouldn’t that mean that transactions are submitted to the Vega application, not Tendermint? Or are these SubmitTransaction messages just passed straight to the Tendermint service by the Vega binary for a checkTx?
“The Tendermint consensus protocol communications between nodes always use the node’s Tendermint key” doesn’t fit with my understanding. I thought tendermint uses a special peer exchange key to verify an agent on the network. Still a tendermint key, but not the conensus key.
I’ve had another look at the Tendermint docs now, and with your explanation have decoded them a bit more.