SGN Architecture¶

CELR Staking¶

Celer layer-2 platform uses delegated proof of stake (DPoS) to reward every shareholder on mainchain and enable fast transactions on sidechain. DPoS is a common consensus mechanism that uses a token staking and election process to achieve both decentralization and high performance in a blockchain system. It provides the opportunity for shareholders (delegators) to vote on potential sidechain validators by staking tokens on them so that every shareholder can make some influence on the network behavior and benefit from it. The properties of DPoS and its comparison with other consensus approaches have been extensively discussed in the blockchain community, so they will not be elaborated in this site. We have adopted some concepts and design choices from various DPoS mechanisms used in existing blockchains.

While SGN is a layer-2 sidechain, the staking process happens on the layer-1 mainchain. CELR shareholders interact with the mainchain contract to stake and withdraw their tokens, and to claim rewards. The validators elected on the mainchain produce, broadcast, and validate blocks for the sidechain. The mainchain DPoS will be shared by all Celer layer-2 systems, including SGN and the upcoming hybrid rollup sidechain. This site currently only describes the architecture of SGN.

Loosely Coupled Architecture¶

SGN mainchain and sidechain are loosely coupled. This design enables higher flexibility, scalability, resilience, extensibility, and maintainability in each component.

Mainchain contracts require elected 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 consensus protocol and produce sidechain blocks. More specifically, mainchain contracts accept claimed sidechain events that are co-signed by validators collectively owning more than 2/3 of the voting power. These events mainly include CELR rewards and penalties.

On the other hand, validators monitor and follow the mainchain events to adjust the sidechain settings accordingly, without caring about how the events are computed in detail. Whenever the validator set and staking pools on the mainchain contract change, the sidechain should immediately update its validator memberships and voting powers. Another mainchain state to follow is the user service fee, which is used by the validators to do sidechain service access control.

Become a Validator¶

Anyone can initiate itself as a validator candidate on the mainchain contract. If the current number of validators is smaller than max_validator_num, the candidate can become a bonded validator when its staking pool meets the minimal staking requirements. If the number of validators has already reached the max_validator_num, then the candidate can become a validator only if its pool size is greater than the current smallest validator staking pool. The replaced former validator and its staking pool will go through an unbonding state, and then become unbonded after a timeout.

When submitting the initializeCandidate transaction, a validator candidate needs to specify a few parameters to help delegators to decide whether to stake on this pool:

• min_self_stake : Minimum amount of CELR from the validator itself to be staked in the pool. The staking pool will be unbonded if the validator’s self-delegated stake falls below this limit.
• 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_time : The mainchain block time until which the commission rate will be locked. This value can be updated anytime after initialization, but must be be monotonic increasing.

After the candidate is initialized, it should submit a updateSidechainAddr transaction to the SGN contract to claim its sidechain node address. When the candidate is eligible to become a bonded validator, it should call the claimValidator function to trigger the mainchain state transition.

Delegate Stake¶

CELR holders including the validator itself can call the delegate function to stake on a validator by locking their tokens in the validator staking pool, which serve as collateral for the validator to provide secure and reliable services. Both the validator voting power and the pool reward are proportional to the amount of staked tokens in the pool. When delegator stake 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.

Withdraw Stake¶

If a validator is in bonded status, all tokens in the staking pool are also bonded as collateral and cannot be freely transferred. If a delegator wants to withdraw its tokens from a pool, it needs to issue an intendWithdraw request. Then the requested CELR tokens will be in unbonding status for a certain period, during which they are still liable to be slashed due to validator misbehaving. The requested tokens will become unbonded after the timeout and can be retrieved by the delegator through a confirmWithdraw transaction.

Tokens in the staking pool of an unbonded validator candidate can be directly withdrawn through a withdrawFromUnbondedCandidate transaction.

Reward¶

Validators and delegators get rewards from both DPoS and SGN contracts. DPoS reward pool gets CELR tokens from the ScaleSphere foundation. SGN reward pool gets CELR tokens from the service fees paid by users. Reward distribution is calculated by the sidechain. Reward receivers need first to query the sidechain to get the reward message co-signed by the validators, then submit the message through the redeemReward function call to the SGN contract.

message Reward {
    bytes receiver = 1 [ (soltype) = "address" ];
    bytes cumulative_mining_reward = 2 [ (soltype) = "uint256" ];
    bytes cumulative_service_reward = 3 [ (soltype) = "uint256" ];
}

On receiving a valid reward message co-signed by more than 2/3 voting power, the SGN contract will transfer the service reward to the receiver, and trigger the DPoS contract to transfer the mining reward to the receiver accordingly.

Penalty¶

The DPoS contract also accepts reports from the sidechain to slash a portion of the stakes from misbehaving validators and their delegators. Once the sidechain validators detect and reach consensus on who and how much to slash, they will co-sign a penalty message and submit to the DPoS contract through the punish transaction.

message Penalty {
    uint64 nonce = 1;
    uint64 expire_time = 2;
    bytes validator_address = 3 [ (soltype) = "address" ];
    repeated AccountAmtPair penalized_delegators = 4;
    repeated AccountAmtPair beneficiaries = 5;
}

On receiving a valid penalty message co-signed by more than 2/3 voting power, the DPoS contract will slash tokens from the penalized delegators (field 4) accordingly. By default, all slashed tokens will go to the shared DPoS reward pool. As will be discussed later, the penalty caused by service failure may specify beneficiary accounts (field 5) who can receive a portion of the slashed tokens.

Governance¶

SGN is operated by a decentralized organization consists of all CELR holders. It requires a well-defined governance mechanism to coordinate any system changes, including contract upgrade, parameter update, new service launch, etc.

A mainchain contract governance process starts with a transaction to create a proposal. Any validator can vote with yes, no, or abstain. A two-thirds staking majority yes vote is required for the proposal to pass. Each proposal requires a deposit to prevent spamming. The proposer can only get back the deposit if the proposal passed. Otherwise, the deposit goes to the reward pool.

A more comprehensive mainchain governance mechanism will be introduced later to implement more rules and let all delegators participate in the governance process.

Service Fee¶

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 model. 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.

Using Tendermint¶

SGN sidechain validators reach consensus through Tendermint, which is a blockchain software that performs BFT state machine replication on many machines. It is built with DPoS support, as the consensus is not based on two-thirds of the machines, but on proportions of the voting power of the machines. Its generic application interface allows developers to program their own deterministic finite state machine logic.

Validators run the SGN service as a Tendermint application so that all nodes have the same request execution logic and a consistent view of current states. The application consists of a set of modules for reward, slashing, state channel guard, sidechain governance, etc. The sidechain does not use a traditional gas model to charge fees for user each transaction. Instead, it performs access control for user requests according to the user service fee balance on the mainchain contract.

Bridge with Mainchain¶

As described previously, mainchain and sidechain are loosely coupled, and the sidechain needs to follow the mainchain to adjust its states. Each sidechain validator runs a process to monitor the mainchain contracts, and follows a round-robin schedule to act as the puller to bridge infomation from mainchain to sidechain.

Once a mainchain event is caught, the current puller would send a change message to the sidechain, along with the event type and updated mainchain information. On receiving a new change message, all validators will independently verify the message by querying information on the mainchain contracts, and vote to accept or reject the message. Once the message is validated by more than 2/3 voting power, it will be applied to the sidechain state machine.

Reward Distribution¶

Rewards are calculated on sidechain in each reward_epoch. They are distributed to the validator staking pools in proportion to their amounts in the current epoch. Each validator takes a cut from its staking pool rewards according to its commission_rate. Then all delegators share the rest of the staking pool rewards in proportion to their stakes in the pool.

Sidechain only calculates and records the reward distribution but does not transfer tokens on the mainchain. The reward receiver can query its reward anytime on the sidechain, and ask for a co-signed reward message from the validators in order to claim the reward on the mainchain.

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.

Horizontal Scaling¶

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.