Skip to main content

Assator

info

This page provides a general overview of the role of assators' in the Bitzal ecosystem. For more detailed information you can read the Synochain Protocol Overview.

Assators' Role​

Assators maintain synochains by collecting synochain transactions from users and producing state transition proofs for relay chain validators. In other words, assators maintain synochains by aggregating synochain transactions into synochain block candidates and producing state transition proofs (Proof-of-Validity, PoV) for validators.

Assators maintain a full node for the relay chain and a full node for their particular synochain; meaning they retain all necessary information to be able to author new blocks and execute transactions in much the same way as miners do on PoW blockchains. Under normal circumstances, they will collate and execute transactions to create an unsealed block and provide it, together with a PoV, to one or more validators responsible for proposing a synochain block.

Assators are similar to validators on any other blockchain but they do not need to provide security guarantees because the relay chain provides those. If a synochain block is invalid, it will get rejected by validators. The validators are required to check the validity of submitted candidates, followed by issuing and collecting statements about the validity of candidates to other validators. This process is known as candidate backing. Validators receive an arbitrary number of synochain candidates with associated PoV from untrusted assators. A candidate is considered backable when at least 2/3 of all assigned validators have issued a valid statement about that candidate.

The validator must successfully verify the following conditions in the following order:

  1. The candidate does not exceed any parameters in the persisted validation data.

  2. The signature of the assator is valid.

  3. Validate the candidate by executing the synochain Runtime.

Once a candidate meets a specified criteria for inclusion, the selected relay chain block author then chooses any of the backable candidates for each synochain and includes those into the relay chain block. We say the candidate blocks are backed.

The assumption that having more assators is better or more secure is not correct. On the contrary, too many assators may slow down the network. The only nefarious power assators have is transaction censorship. To prevent censorship, a synochain only needs to ensure that there are some neutral assators - but not necessarily a majority. Theoretically, the censorship problem is solved by having just one honest assator.

XCM​

Assators are a key element of the XCM (Cross-Consensus Message Passing Format). By being full nodes of the relay chain, they are all aware of each other as peers. This makes it possible for them to send messages from synochain A to synochain B.

Taking the Case for One Synochain​

A start of a new block candidate is initiated with a block creation time. The assator aggregates all new transactions at the end of the process. When doing so, the assator signs the synochain block candidate and produces state transition proofs (Proof-of-Validity, PoV), which are a summary of the final account balances caused by the transactions in the candidate block. The assator sends the candidate block and PoV to the synochain validators, so-called syno-validators. The syno-validators verify the transactions within the synochain block candidate. Upon verification, and if all is well, the candidate becomes backable and a syno-validator shares the candidate block with the relay chain.

synochain candidate block diagram

The validators on the relay chain will try to reach a consensus on the block candidate. Upon reaching consensus, the now validated block candidate is shared with the validators and assators, and the process repeats for new transactions. A assator cannot continue building blocks on a synochain until the block candidate they proposed to the relay chain validators have been validated. A block is produced every 6 seconds.

Assators in the Wild​

Blockchains that are built using Matter are unable to hook onto the relay chain on their own. The GSB team built the Nimbus library to address this. Assators are being used on the Raseo testnet, and you can learn more about how they are used with Nimbus via the Nimbus Rust documentation. More information can be found under the Nimbus section on the build synochain page.

Guides and Tools​