This page is WIP.
State guardian network (SGN) is an efficient and scalable sidechain that eliminates the state channel security risks and usability hassles caused by the off-chain availability problem. It provides highly reliable and decentralized services including payment channel guardian, delegated payment receiver, and app connectivity oracle for Celer state channel users.
Figure above shows the high-level SGN sidechain architecture. It mainly consists of four components: mainchain smart contracts, token delegators, sidechain validators, and sidechain users. Below we summarize the rights and responsibilities of each component:
- Mainchain contracts specify and enforce the highest law. Mainchain manages rules, roles, stakes, rewards, punishments, and fees for all network participants.
- Delegators stake their CELR tokens on the mainchain contracts to vote on validators and governance proposals. Delegators receive rewards proportional to their stakes.
- Validators are elected by the delegators to run the SGN services as sidechains under BTF consensus and report to the mainchain. They also have higher responsibilities in mainchain governance. Validators receive commission rewards from their delegators.
- Users are state channel clients who pay subscription fees to the mainchain contract and submit service requests to the sidechain.
Delegated Proof of Stake¶
Delegated proof of stake (DPoS) is a common consensus algorithm designed as a form of technological democracy, using a token staking and election process to achieve both decentralization and high performance in a blockchain system. DPoS provides the opportunity for shareholders (delegators) to vote on potential validators by staking tokens on them, so every token holder is able to make some influence on the network behavior. The elected validators produce, broadcast, and validate blocks for the blockchain. The properties of DPoS and its comparison with other consensus algorithms have been extensively analyzed, so will not be elaborated in this article.
SGN uses DPoS on mainchain to manage the validator set and reward distribution because of its two major benefits: 1) enable fast sidechain transactions, 2) reward every shareholder. We adopt some core concepts and design choices from various DPoS mechanisms used in existing blockchains such as Cosmos, POSDAO, and BitShares.
Becoming a Validator¶
Any mainchain address can become a validator candidate by creating a CELR staking pool in the mainchain contract. If the current number of validators is smaller than
max_validators, the candidate becomes a validator immediately when its staking pool is non-empty. If the current validator set has already reached the maximum number of validators allowed, then the candidate can become a validator only if its pool size is greater than the current smallest validator pool. The replaced validator becomes inactive, and tokens in its staking pool are unlocked.
A validator needs to specify a few parameters on the mainchain along with the
createPool transaction to help CELR holders to decide whether to stake on this pool.
sidechain_address: The sidechain node address of the validator.
commission_rate: The commission rate on the staking rewards to its delegators. This value can only be updated after the lock end date specified below. When the validator wants to increase the rate, it also needs to announce the update two weeks before the new rate takes effect.
rate_lock_end_date: The date until which the commission rate will be locked. This value can be updated anytime after initialization, but must be be monotonic increasing.
min_self_stake: Minimum amount of CELR from the validator itself to be staked in the pool. The staking pool will be unlocked if the validator’s self-delegated stake falls below this limit.
Stake and Withdraw¶
CELR holders including the validator itself can
stake on a validator by locking their tokens in its staking pool, which serve as collateral for the validator to provide secure and reliable services. Both the validator’s voting power and the pool’s reward are proportional to the total amount of staking tokens in the pool. When non-validators stake (delegate) their tokens on a validator, they share rewards as long as the validator follows the protocol, but also share the risks of getting punished if the validator misbehaves due to any reason.
All staking tokens are
locked in the staking pool as collateral and cannot be freely transferred. If a participant (delegator or validator) wants to withdraw its staking tokens from a pool, it needs to issue an
intendWithdraw request. Then the requested CELR tokens will be in
unlocking status for a certain period of time, during which they are still liable to be slashed due to validator misbehaving. The requested tokens will become
unlocked after the waiting period and can be retrieved by the requester through a
Bridge from Sidechain¶
SGN mainchain and sidechain are loosely coupled. Mainchain requires validators to reach BFT consensus when reporting sidechain events, but does not care how do they achieve it. It’s up to the validator themselves to run their own consensus protocol and produce sidechain blocks. More specifically, mainchain contracts accept whatever events the validators claim as long as more than 2/3 total voting power agree. These events include rewards, penalties, optionally sidechain transaction summaries, etc. There are three ways for the mainchain to accept events from the sidechain:
- Two-thirds signatures. The mainchain contracts accept any events that are signed by validators collectively owning more than 2/3 of the voting power. This is the most straightforward way for an event to be reported with instant finality.
- Claim and challenge. For events to be reported more frequently such as transaction summaries, the sidechain can schedule one validator to do the reporting without any others’ signatures, while other validators monitor the reports and challenge if needed.
- Proposal votes. When validators with no less than 1/3 voting power go offline or censor the sidechain transactions, any other validator can initiate a reorg-proposal to let all stakeholders to vote on such decision following the governance protocol.
Reward and Penalty¶
Validators and delegators get rewards from the mainchain contract rewards pool. Rewards pool gets tokens from two resources: the CELR mining pool filled by the ScaleSphere foundation, and the service fees collected from users. Reward information is calculated by the sidechain, signed by the validators, and redeemed on the mainchain by the reward receivers.
The mainchain contract also accepts reports from the sidechain to slash a portion of the staked tokens from misbehaving validators and their delegators.
Users who want to receive the SGN sidechain services should send payments to the mainchain contract. The fee structure is advertised by the sidechain as a subscription or pay-per-use mode. In either case, the sidechain tracks the service usage and user remaining sidechain balances. A user should make an upfront lump sum payment on the mainchain, and then send as many sidechain service requests until the remaining sidechain balance becomes zero.
SGN is operated by a decentralized organization consists of all CELR holders. It requires a well-defined governance mechanism to coordinate any changes to the system, including contract upgrade, parameter update, new service launch, etc. Since the mainchain contracts specify the highest law of SGN and the sidechain configuration just needs to follow the mainchain, the governance process only involves changes to the mainchain contracts.
A governance process starts with a
createProposal transaction. Anyone who has stakes in the mainchain contract can vote with yes, no or abstain. A two-thirds majority (excluding abstentions) yes vote is required for the proposal to pass. All validators are required to vote on every proposal within a timeout window, and will be punished if they failed to do so. Delegators can vote after its validator. If a delegator does not vote, its vote is considered the same as its validator.
To prevent spamming, each proposal requires a
proposal_deposit. The proposer can only get back the deposit if the proposal passed. Otherwise, the deposit goes to the reward pool.
The elected validators run the sidechain services under BFT consensus, which can tolerate up to 1/3 of the voting power failing arbitrarily. SGN chooses to use Tendermint as the sidechain BFT consensus engine because of its flexibility and proven stability. SGN supports parallel sidechains to scale out the services and achieve ultra-high performance with no compromise on security or decentralization. This section describes how SGN sidechain consensus works in general. Later sections explain how to support each service in detail.
Tendermint is a blockchain system software that performs BFT state machine replication on many machines. It is built with DPoS support, as its consensus is not based on two-thirds of the machines, but on proportions of the total voting power of the machines. Its generic application interface allows developers to program their own deterministic finite state machine logic. Validators run the SGN services as Tendermint applications, which means that all nodes have the same request execution logic and a consistent view of current states.
The SGN Tendermint application consists of two sets of components: core modules and service modules. The core modules bridge mainchain and sidechain, reflect the real-time mainchain states on the sidechain, and report sidechain events to the mainchain. The service modules define the actual SGN services as easy application plugins. The SGN Tendermint application does not use a traditional gas model to charge fees for each transaction. Instead, the application read the subscription info from the mainchain to perform access control for sidechain requests.
Validators need to closely follow the mainchain contract states and adjust the Tendermint sidechain settings accordingly. The most important parameters to follow are the validator set and staking pools on the mainchain. Whenever these values change, the sidechain should immediately update its Tendermint consensus participants (validators) and the voting power of each participant. Another critical mainchain state to follow is the user subscription info, which provides the rules for validators to do service access and rate control.
One minor challenge needs to be addressed is that for PoW blockchains such as Ethereum, the validators may have slightly out-of-sync views of the mainchain latest block, and the latest block state may get reverted. In order to guarantee all validators always maintain the consistent and correct sidechain state, validators need to tolerate some mainchain block delays when updating local states. Each validator has a monitor process listening to mainchain events. Once an event is caught, the validator should wait for a while before broadcasting the event, to make sure other validators able to verify it on the mainchain. A simple scheduling scheme is applied to avoid all validators trying to update the same event, which is a waste of transaction throughput.
Reporting to Mainchain¶
The sidechain reports to the mainchain about events such as validator misbehaviors and optional service transaction Merkle proof summaries through the previously described methods. Validator misbehaviors are reported through two-thirds signatures, while service transaction summaries may also be reported through the claim and challenge method for cost-efficiency.
Rewards are calculated in each
reward_epoch and split into two portions: most (e.g., 95%) rewards are distributed to the validator staking pools in proportion to their staking amount, while the rest are evenly shared by the staking pools. The purpose of the later is to encourage staking decentralization, discourage one or a few validators owning too much voting power.
Each validator first takes a cut from the rewards of its staking pool based on its current
commission_rate. Then all stakeholders share the rest of the staking pool rewards in proportion to their stakes in the pool.
Penalties for Misbehavior¶
The sidechain punishes misbehaving validator and its delegators by slashing a portion of the tokens from their staking pool on the mainchain contract. There are currently three slashing conditions:
- Double sign blocks. If a validator signs two conflicting blocks at the same height, it will get slashed by X%. The slashed tokens go to the reward pool.
- Miss blocks. If a validator misses more than 95% of the last N blocks, it will get slashed by Y%. The slashed tokens go to the reward pool.
- Break service agreement. If a validator fails to finish a service task during its assigned time slot, it will get slashed by Z%. Half of the slashed tokens go to the reward pool; the other half are rewarded to the validator who finished the same task at a later assigned time slot.
SGN can be easily scaled out by running multiple parallel sidechains due to the shared-nothing nature of the services it provides. Each type of service is entirely independent, so it can be run independently. All requests within a service can also be executed in parallel, because all SGN services are essentially storing and operating on the independent off-chain states for individual users. There is no double-spending problem in SGN sidechain.
All sidechains are run by the same validators. For example, if service A has X sidechains, service B has Y sidechains, and service C has Z sidechains, then each validator needs to run X+Y+Z machines for all the sidechains. Each service applies user-based sharding, which means requests from one user always go the the same sidechain, while different users may be served by different sidechains.
All sidechains follow the mainchain validator set and staking info under the same logic. The slashing conditions and reporting methods also remain the same, since the mainchain contracts only care about the validator signatures and votes.