Blockchain
Last updated
Last updated
Each account is identified using an Address which is a sequence of bytes derived from a public key. Sphinx defines four types of addresses that specify a context where an account is used:
Address and keypair for regular user accounts, generated using the secp256r1 curve.
Address and keypair for Validator nodes, generated using the secp256r1 curve.
Address and keypair for Consensus nodes, which identify validators participating in consensus. Generated using the tm-ed25519 curve.
Address and keypair for SubAccounts, identified as accounts tied to a Coprocessor. They are generated using the secp256r1 curve.
sphx
sphxpub
secp256r1
20
33
sphxvaloper
sphxvaloperpub
secp256r1
20
33
sphxvalcons
sphxvalconspub
tm-ed25519
20
32
sphxcopro
sphxcopropub
secp256r
20
33
SubAccounts are a new account type exclusively for use by Coprocessor nodes to facilitate off-chain transaction execution. These are generated using signed transactions the sphxpub keypair, and are cryptographically linked and owned by the on-chain parent account.
We discuss more about SubAccounts, state synchronization and use cases in the Coprocessor design brief.
Sphinx leverages CometBFT as it's underlying consensus engine. With the introduction of ABCI++, our application layer can receive the block proposal before the voting period commences. Leveraging this to optimistically execute the block proposal in parallel with the voting process significantly reduces our block times. We leverage the ProcessProposal call to execute FinalizeBlock ahead of time
The worst case scenario is when a node reaches FinalizeBlock while executing the wrong block. In FinalizeBlock we check to determine if the hash in the current request (RequestFinalizeBlock) matches the hash of the block being executed in the running execution, if they don’t match we proceed to abort and discard the result. The block processing will abort for the current cycle only and start over with the original block.
Coming soon....
