Inflation in Liquid Proof-of-Stake Models

Tezos Explainer: Liquid Proof-of-Stake

Today, as we have seen the effects of decentralization following the Athens proposal getting activated on the Tezos protocol, a topic that is of significant importance to the Tezos protocol, is “invoicing” or inflation. In this post, we will look at the effects of inflation, examine key developers insight on inflation, and look at the process directly through the code in Liquid Proof-of-Stake (LPoS) models — Tezos.

LPoS Under the Hood

In contemporary blockchain consensus models such as Delegated Proof-of-Stake (DPoS), election of a fixed number of block producers (delegates) is required to maintain network consensus. Within Liquid Proof-of-Stake (LPoS) models, delegation is optional, thus anyone can participate in facilitating network consensus through choosing a baker or exercising their own forthright views on governance as long as they own a roll.

In this sense, through LPoS, Tezos has accomplished something remarkable, allowing it to flow between two cycles of democratic governance. On one end of the spectrum, there exists pure representative democracy, characteristic of DPoS in the form of choosing a baker. On the other end, simultaneously, there exists pure liquid democracy in the form of also allowing network consensus through a sole baker, contingent upon owning a single roll of XTZ.

Examining Invoicing

Invoicing is a mechanism unique to Tezos’ on-chain governance structure which allows the ability to fund core development and other public goods. The process can be detailed in further length below, showing how Tezos’ governance structure works:

• A dev team injects the hash of a tarball file as a proposal into the Tezos Protocol with an invoice attached.
• The injected proposal goes through 4 phases.
• The first phase, known as the initial voting period, is where bakers will vote and decide if the proposal is best for the protocol. There can be a maximum of 20 proposals per baker in this phase.
• The second phase, known as the exploration voting period, is where another vote is made to move forward. During this phase, 80% Quorum is needed to vote “Yay” and proceed with a testing period of the proposed changes. The Quorum adjusts accordingly and won’t always 80%. This phase also requires to meet supermajority to proceed.
• The third phase, known as the testing phase, is where a temporary blockchain is formed for testing purposes. If things run smoothly and there are no significant problems, a final promotional period will begin.
• The final phase, known as the promotional period, is where a final vote is cast on the proposed changes. During this final phase, if voted through, the new protocol will be added automatically with the new code and the protocol mints the tokens attached as an invoice in the proposal. If it does not go through, it goes back to the proposal phase.

Through Tezos’ formal on-chain governance, such as we’ve seen successfully executed within Athens; Nomadic Labs, the team behind the Athens proposals, were paid automatically 100 XTZ directly to their wallet following the successful activation of the proposed protocol amendment. Thus, the first instance of invoicing was born.

Invoicing works through raising the total token supply of XTZ (inflation). Therefore, when Nomadic Labs received 100 XTZ after the Athens protocol amendment was successfully activated, these tez were minted directly from the Tezos protocol. Through this open and permissionless process, there is no central authority that evaluates what can be proposed and/or the amount a dev team can attach as an invoice. It is fair, uniform, and devolves all decision-making powers directly to the token holders. Thus, the token holders are in essence the owners, operators, and governors of the network.

On the same note, it is also possible to those dev teams who submit an invoice attached within their proposal, could also submit multiple amounts, some of which could be going to completely other projects or even, charity. In this sense, funding of core development is thrown out at what will be popular within the community and consequently, taking the Tezos Foundation out of the loop in the process completely.

Additionally, a further inducement to adhere to regarding invoicing is that it can also lead as a potential solution to the free-rider problem that open-source projects are particularly prone to.

“Name Your Price”

The idea of essentially being able to “name your price” and have anyone come in and propose a core development protocol amendment is something of a novelty. With this in mind, nearly all of Tezos’ code is published within GitLab. Therefore, for the purpose of truly showing how invoicing works, we will look into the recent “Brest A” Amendment and examine invoicing directly on-chain through TzScan and GitLab.

• OcamlPro, the team behind the Brest A amendment, has injected the hash of a tarball file as a proposal to the protocol. In order to submit a proposal, the following command must be compiled:

./tezos-client submit proposals for <DELEGATE> <PROTOCOL-HASH>

• OcamlPro proposes 8,000 XTZ to be rewarded for their work on the “Brest A” Amendment and has attached an invoice for said amount. Namely, a security and tooling issue. See Fabrice’s comments here.
• Brest A has passed the promotion phase, as indicative on TzScan.

• Using the TzScan key, shows the current period, formal period, and coming periods within the amendment process.

• As of July 9, 2019, Brest A is currently in the exploration phase. Of all the votes by bakers, 0.05% is for “Yay”, 17.01% is for “Nay”, and a majority 82.94% is for “Pass”. The number of ballots cast can be seen below along with the quorum threshold (as of July 9, 2019).

• The relationship between the percentage of baker ballots cast and the number of votes can be further examined in the following pie chart (as of July 9, 2019).

As we can glean from the specific proposal, a majority of bakers have “passed” and voted “nay” on the proposed protocol amendment by OcamlPro. The votes for “nay” and “pass” encompass a whopping 99.95% percentage of all total ballots cast by bakers. It’s important to realize that 1 vote is equivalent to 1 roll of XTZ, or roughly 8,000 XTZ now, following the recent Athens A proposal getting passed and activated on the protocol.

Therefore, we can see a staggering majority exercising their forthright views on governance by downvoting the recent Brest A amendment. In this particular instance, through the community, we can see consensus exercised as something it does not approve of with 99.95% of all bakers voting “pass” or “nay” for Brest A.

Through this example, the quorum will likely adjust for the next vote. Instead of 80% needed, it will likely be in the 70% range. The reason for this stems from a built-in quorum adjustment mechanism within the amendment process. This built-in mechanism, further enumerated in Jacob Arluck’s Amending Tezos, protects against voter stagnation and takes into account any lost coins that may affect a vote.

A Developer’s Perspective on the Future of Invoicing

Since we’ve already discussed inflation within LPoS models, some questions may begin to arise. How will developer teams look to upgrade the Tezos protocol through the amendment process go about choosing an amount to attach in an invoice? What are some of the possibilities with invoicing? These questions and more, I decided to ask Awa Sun Yin of Cryptium Labs in an interview. Below are my questions in bold and Awa’s responses in quotation.

How will you and your team go about deciding the amount to ask for in future proposals?

This depends a lot on what kind of proposal it is. Assuming that you’re referring to core protocol development (OCaml codebase, etc), the amount we request is based on how many people we require to work on what project (s). As a young team, we have learnt to budget better overtime, as e.g. there are a lot of significant costs that cannot be foreseen unless you went through them.

What do you think the future of invoicing holds? Lastly, what possibilities do you see with inflation funding?

I’m assuming you’re referring to invoicing on-chain? In that case we have brainstormed with the help of some groups in the ecosystem (Nomadic, the TF, TQ, other collaborators) on a short, long term plan to eventually make core protocol engineering financing directly on-chain. At the moment we are gonna rely on attaching invoices with the proposals, probably with larger amounts than 100 XTZ with the purpose of experimenting with the process and getting some feedback and sentiment from the community. Invoices are just one way, there are many other interesting ideas for the mid-longer term: e.g. initiating community pools, token issuance, combination of invoices with other funding sources etc.

Through some of Awa’s responses, one can glean and understand invoicing directly through the lenses of a development team working on implementing multiple proposals on the Tezos protocol in the coming weeks/months. As invoicing eventually gets tested more, it will provide a formal on-chain method of financing which could lead to several implications against open-source funding. In this sense, invoicing is just one of many interesting funding mechanisms within Tezos and the mid-longer term could consist of several other methods of financing directly on-chain.

Conclusion

Ultimately, inflation funding can pave the way for teams to begin working for public blockchains, like Tezos, as opposed to private companies; where compensation for advancing the protocol can be automatically paid directly to a developer’s wallet following the activation of a new protocol amendment.

It’s in this sense, after watching and monitoring the governance process within Tezos, and seeing that you can essentially “name your price” and get paid automatically with the full backing of the community behind you, of proven merit; the notion is brought forth — “Hmm, even I could do this”.