Table of Links
V. Purchasing-Power Adjusted Transaction Fees
VII. Trusted Execution Environment Security
VI. ARCHITECTURE
In this section we describe the system architecture for Encointer as a Polkadot parachain (or parathread) using the SubstraTEE framework. Explaining these technologies is beyond the scope of this paper and the reader shall refer to [9] and [17].
Figure 3 shows the entire stack of the Encointer platform.
A. Relay Chain
At the lowest level, we have the Polkadot relay chain as a NPoS-validated root-of-trust. The relay chain’s native token is the DOT and the block time is 6s.
Parachains need to bond DOTs in order to get a slot
B. Parachain
The Encointer parachain enjoys the security of the underlying relay chain and serves the following purposes:
• registry for remote-attested TEEs who provide sidechain validation
• finality for sidechain blocks
• global scheduling of ceremonies
• registry of community currencies and their parameters
There is no need for the parachain to have its own native token, therefore it will use DOT for fee payments. Sidechain validators will have to pay parachain fees in DOT to have their TEE attested and their blocks finalized. Users will not usually interact with the parachain directly but fees for registering a new currency have to be paid in DOT as well.
Parachain fees are expected to be marginal as they only serve the purpose of spam-prevention. There are no validators that need to be incentivized. While collators are needed for availability to produce blocks which are then validated by relay-chain validators, their role is not security critical. Encointer communities will have a strong intrinsic incentive to run collators without much compensation.
It should be said that there is no guarantee that Encointer can become a parachain as the slots are limited. Auctions where DOT holders can bond their DOTs for parachain candidates will determine slot allocations. Should Encointer not win a slot, it could still run as a parathread where DOTs have to be paid for each validated block. The confirmation time for finality will be much longer in that case, but sidechains would not be affected much.
C. Sidechains
The Encointer sidechains maintain the community currency balance ledger and perform the Encointer protocol for uPoP (See III). Each community has its own shard holding its confidential state.
The sidechain validators are run in TEEs to get both integrity and confidentiality. As TEEs are considered to be trusted, there is no need for a consensus protocol for sidechain blocks. This simplifies the design significantly and allows for sub-second block times due to a low communication overhead.
Sidechain validators can only operate a limited number of shards per machine. Therefore we expect local communities to take care of their own sidechain validator infrastructure.
Running sidechain validators for any shard is unpermissioned. Every remote-attested TEE will be provisioned with the necessary keys to participate in block-production. All sidechain validators run the same code which is asserted by remote attestation.
Author:
(1) Alain Brenzikofer ([email protected]).
This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license.