Yesod Release Candidate — 1

A potential upgrade to Zen Protocol, “Yesod-RC1” — git commit ID 05d38f0f9a2aae6cd52cd0650d4880461dabc936 — is now available for community review.

The proposal provides coin holders with a financial toolkit, which is complimentary with the latest governance upgrade.

This proposal enables coin holders with the ability to:

1. Distribution of block rewards — A monthly vote is held where users can choose to divert a portion of the coins created by block rewards between miners and the CgpContract.
2. The ability to determine where the funds that are held in custody by the CgpContract will be sent.

Nomenclature

The proposal introduces a few new concepts which are discussed in our technical reference, and are also defined here:

• Blockchain Intervals — a period of 10,000 blocks.
• Voting Intervals— The last 1,000 blocks of a Blockchain Interval, which is divided into 2 phases, the Nomination Phase and the Voting Phase.

1. Nomination Phase
   This phase spans the first 500 blocks of the voting interval, during which coin holders can nominate a PayoutBallot.
   PayoutBallots must meet the required threshold amount of nominations — 3% of outstanding ZP — in order to pass on to the next phase.
2. Voting Phase
   This phase spans last 500 blocks of the voting interval, is when a community vote is held on both the AllocationBallots (winner is calculated using a weighted median) and the PayoutBallots (winner is calculated using a first-past-the-post model). In the event of a tie there are no winners.

Note: The Nomination Phase is only for the PayoutBallots, as the use of 2 phases results in a situation that all PayoutBallots are disclosed at least 500 blocks in advance. Thus if a malicious PayoutBallot is created (e.g. unjustified draining of all the CGP assets) the community will have time to notice and act against the actor.

• SnapshotBlock — The last block before the voting interval starts. Your vote weight is calculated based on your ZP balance at the SnapshotBlock.
• TallyBlock — The block in which the winner is computed, which occurs in the first block in the next interval.
• PayoutBlock — Occurs 100 blocks after the start of the BlockchainInterval, and includes the PayoutTransaction of the winner determined in the TallyBlock preceding it.
• PayoutBallots — The serialized representation of a recipient address, and a list of assets & amounts. E.g. Alice | (10 ZP) & (2 USDZ).
• AllocationBallots — The serialized representation of the % of the coinbase transaction that must be allocated to the CgpContract.
• VotingContract — An empty contract that is used as a placeholder to collect metadata.
• CgpContract — A custodian contract whose funds are dispersed, subject to a coinholder vote. Accumulates funds from AllocationOutputs and donations, and then dispenses funds in PayoutTransactions.

CGP Architecture

A smart contract that acts as a custodian of funds is implemented by using the contract system. The CgpContract works exactly like any other contract. While use of the contract mechanism is efficient, it is also insufficient.
Currently, the Zen Protocol blockchain does not provide contracts with the necessary context to independently determine the outcome of the community vote (i.e. the ability for a contract to determine the outcome of a community vote on its own)

Therefore the CGP contract operates on an “anyone can spend paradigm”. Every 10,000 blocks — aka a “PayoutBlock” — the contract will consider any transaction which spends tokens locked to it as valid. I.e. the contract allows anyone to take any amount of funds they desire from the CGP, so long as the transaction is executed in a PayoutBlock.

In order to get around this obvious vulnerability, we have modified the blockchain such that the node conducts an extra step of validation for Payout Blocks — verifying that the Payout Transaction in an incoming block matches the PayoutTransaction that the node expects to see in the PayoutBlock. This expectation is due to the output of computation — which is saved as the “CgpState” — which occurs in an independent process. To work around this matter, we have modified the blockchain such that the node conducts an extra step of validation every 10,000 b locks. Prior to accepting a PayoutBlock as valid, the node computes the tally (i.e. the winning PayoutBallot) each voting interval.

The node then will validate that in a PayoutBlock the following conditions exist:

• The CgpContract is executed exactly once in the PayoutBlock, if a winner was computed. (i.e. The PayoutTransaction must be included, and there is no avenue for a replay attack).
• The PayoutTransaction which matches the result/tally of the PayoutVote, the node will consider (that) PayoutBlock a valid extension of the blockchain.

However if the PayoutTransaction and the Tally are not equivalent, the block is considered invalid, even if the contract validates the transaction.
Thus an effective deterrent is in place, miners will only include a PayoutTransaction which transfers funds to the rightful recipient, or their block will not be included in the network.

For practical purposes the CgpContract has two sources of revenue:

• AllocationOutputs — A portion of the BlockReward which is diverted to the CgpContract. Each Block the CgpContract receives X% of the BlockReward.
• Donations — Funds sent to the CgpContract by the user (or a smart contract) arbitrarily.

By using a contract to store funds we get additional advantages:

• Preservation of the UTXO model.
• Introduction of less technical debt, and a design which is more “conventional” by using a smart contract to store funds.
• The rate of coin creation (i.e. the supply/issuance curve) is unchanged.
• The CGP can store any asset in its custody,,
  rather than it’s previous limitation to only storing ZP.

The RC-1 network provides a testing blockchain with some different configuration:

• A shuffled genesis block of the mainnet was used as the genesis for the RC-1 network, allowing Zen Protocol Token Holder to try the network with their real ZP balance but securely enough to not copy cat transaction to the mainnet.
• The interval length is set to 100 blocks instead of 10,000 as in mainnet
• The maturity is 10 blocks instead of 100 as in mainnet
• The snapshot is the 90th block in each interval instead of the 900th as in mainnet
• The nomination phase is 5 blocks instead of 50 as in mainnet
• The voting phase is 5 blocks instead of 50 as in mainnet
• The threshold is 0.3 % of the total ZP issuance instead of 3% as in mainnet