In the previous post “On-Chain Random Oracle on EVM”, we mentioned that DEXON is able to utilize the block threshold signature (t-Sig in short) as a random seed. However, if that is the case, the transactions in that specific block cannot make use of the random seed since the t-Sig is generated after the block is proposed. To solve this, DEXON uses the concept of witness, where the state root of the current block is witnessed (verified) in the following blocks.

When a block is being verified by a block proposer, the block itself contains a Witness structure:

Where the Data field contains the state root and receipt hash of the witnessed block specified with Height .

This allows the block proposers to compute the latest state root locally, and verify it later by comparing it with the later witness information. Unless there are bugs in the implementation, the locally computed Root and ReceiptHash should always be the same as the witnessed ones.

However, the witness mechanism introduced here introduces extra latencies in TX confirmation, since a TX can only be safely announced as confirmed only when the block which the TX resides’ state root is being witnessed. This is the price we have to pay if we want to utilize the random seed. On the bright side, since if the BP is a good actor, the locally computed state root can be trusted. We can expose a pending event (where a block is proposed but not yet witnessed) for applications that require shorter confirmation time, but application will have to trust the BP it connects to.

Below is a picture for visualizing the above flow:

Block state transition during the DEXON consensus flow

Since there is already a Pending block concept in Ethereum, it’s easy for us to map the relationship of the DEXON consensus block states to it.

As one can see, the received blocks formed a block DAG (Yellow blocks). Later after running the total ordering algorithm, they get compacted into a single chain (Blue blocks). However, the blue blocks are in the Pending state as their state root is not yet witnessed. But the blue blocks actually contain the Witness data to witness the earlier blocks, making them a Confirmed block (Green blocks).

That’s it. This is how DEXON is able to utilize the random seed without the attacker being able to predict it as they send the transaction. Stay tuned for more future posts on the internal design of the DEXON blockchain!

Spoiler Alert!

A keen reader might point out that a lazy BP could just copy witness data from blocks other BP proposed and does not actually do any state calculation locally. In the next post, I’m going to talk about how we use a commonly used technique in cryptography to solve this elegantly.