Tezos is a new platform for smart contracts and decentralized applications.

home link https://tezos.com/

reference material Whitepaper.pdf


Exchanges that listed the coin
To be released
Project introduction

Tezos is a block chain that can evolve with its own upgrade. Stakeholders vote on the amendment to the Protocol, including amendments to the procedure to reach a social consensus on the proposed procedure. Tezos provides a platform for supporting smart contracts and building distributed applications.

Executives and partners

Ryan Jesperson


There is no partner information at this time
Please leave a message of support for the team

go to leave a message

Latest News

There is no news posted at the moment
Please leave a message of support for the team

go to leave a message


Spinning up a Tezos node in...

An introduction to booting up a Tezos node using snapshots and history modes.This is a composite post derived from Nomadic Labs’ post: ‘Introducing Snapshots and History Modes for the Tezos Node’ and Nomadic Labs CTO Benjamin Canou’s recent presentation: ‘How to Quickly Boot a Tezos Node: a brief presentation of snapshots and history modes’.Spinning up a node on most blockchains takes an enormous amount of disk space and a long time to sync up to the head of the chain from the associated genesis block. This has also been true for Tezos, which requires approximately 120GB of disk space for archive nodes and a few days (on a typical connection) to synchronize the whole chain since June 30, 2018 (Tezos launch date).The recently introduced ‘History Modes and Snapshots’ feature helps resolve this challenge, making it quick and easy to spin up a Tezos node. A positive outcome of this feature is that it makes it easier for solo bakers to participate and independently secure the system.Let’s do a quick recap of History Modes and then proceed to see how we can use a snapshot to quickly boot a Tezos node. Lastly, let’s see how to do simple Garbage Collection using snapshots to safely recover disk space.History ModesHistory modes allow nodes to run without having to maintain full archives of the chain’s past states.Here are the first three history modes that have been introduced:archive nodes store everything. This corresponds to the current behaviour of Tezos nodes.full nodes store all chain data since the beginning of the chain, but drop the archived contexts below the current checkpoint. In other words, you can still query any block or operation at any point in the chain, but you cannot query the balances or staking rights too far in the past.rolling nodes are currently the most lightweight, only keeping a minimal rolling fragment of the chain and deleting everything before this fragment (blocks, operations and archived contexts).ARCHIVE History ModeThis is the current default mode in mainnet.What you can do with an archive node:safely validate new blocks and operationsbake and endorseaccess all the blocks and operations in historyallow archive nodes to synchronizeaccess all balances at any point in the pastuse a lot of disk space (for now)FULL History ModeThis is the planned new default mode in mainnet as it is sufficient for almost everyone. Running a full node is enough to maintain the full chain history and the network does not lose any security by adopting full as the default.What you can do with a full node:safely validate new blocks and operationsbake and endorseaccess all the blocks and operations in historyallow archive nodes to synchronizea̶c̶c̶e̶s̶s̶ ̶a̶l̶l̶ ̶b̶a̶l̶a̶n̶c̶e̶s̶ ̶a̶t̶ ̶a̶n̶y̶ ̶p̶o̶i̶n̶t̶ ̶i̶n̶ ̶t̶h̶e̶ ̶p̶a̶s̶t̶u̶s̶e̶ ̶a̶ ̶l̶o̶t̶ ̶o̶f̶ ̶d̶i̶s̶k̶ ̶s̶p̶a̶c̶e̶ROLLING History ModeThis is the most lightweight mode, only keeping a minimal rolling fragment of the chain and deleting everything before this fragment (e.g. blocks, operations and archived contexts).What you can do with a rolling node:safely validate new blocks and operationsbake and endorsea̶c̶c̶e̶s̶s̶ ̶a̶l̶l̶ ̶t̶h̶e̶ ̶b̶l̶o̶c̶k̶s̶ ̶a̶n̶d̶ ̶o̶p̶e̶r̶a̶t̶i̶o̶n̶s̶ ̶i̶n̶ ̶h̶i̶s̶t̶o̶r̶y̶a̶l̶l̶o̶w̶ ̶a̶r̶c̶h̶i̶v̶e̶ ̶n̶o̶d̶e̶s̶ ̶t̶o̶ ̶s̶y̶n̶c̶h̶r̶o̶n̶i̶z̶e̶a̶c̶c̶e̶s̶s̶ ̶a̶l̶l̶ ̶b̶a̶l̶a̶n̶c̶e̶s̶ ̶a̶t̶ ̶a̶n̶y̶ ̶p̶o̶i̶n̶t̶ ̶i̶n̶ ̶t̶h̶e̶ ̶p̶a̶s̶t̶u̶s̶e̶ ̶a̶ ̶l̶o̶t̶ ̶o̶f̶ ̶d̶i̶s̶k̶ ̶s̶p̶a̶c̶e̶Booting quickly from a SnapshotAs the chain invariably grows every day, retrieving a full chain from the peer-to-peer network can be a very long process.With the implementation of history modes, it is now possible to have an import/export feature: ‘Snapshots’. This procedure allows one to quickly gather all the data necessary to bootstrap a node from a single file.Snapshots provide the following main advantages:A snapshotted node starts at approximately 500MB (as compared to 120GB for an archive node)Synchronisation to the head can be achieved in a few minutes from a recent snapshot (as compared to a few days for an archive node)Archived contexts can be reconstructed on demand.Step 1: Exporting a snapshot from a full/archive nodeThis needs to be done by some entity that’s running a full or archive node and on a machine that is running mainnet or mainnet-snapshots .> HASH='tezos-client rpc get /chains/main/blocks/head~30/hash | tr -d '''> tezos-node snapshot export --block HASH HASH.full> gzip HASH.fullHopefully in the future, services will pop up to generate frequent snapshots and publish them for public use. Baking services and block explorers are in an ideal position to do this.Step 2: Starting a node from a snapshotThe snapshot format does not (and cannot) provide any evidence that the imported block is actually a part of the current main chain of the Tezos network. To avoid being fooled by a fake chain, it is necessary to carefully check that the block hash of the imported block is included in the chain. This can be done by comparing the hash to one provided by another node under the user’s control, or by relying on social cues to obtain a hash from a large number of trusted parties which are unlikely to be colluding.Then on a fresh mainnet-snapshotsinstallation:> gzip -d HASH.full.gz> tezos-node snapshot import --block HASH HASH.full> tezos-node identity generate> tezos-node run --rpc-addr 'localhost:8732'After this your Tezos node should be up and running in a few minutes.Simple Garbage Collection using SnapshotsAs an aside, the snapshots feature can also be used to drop the archived contexts of a node and recover disk space. This is usually known in the programming language world as Garbage Collection (or GC).> tezos-client rpc get /chains/main/blocks/head~30/hash> tezos-node snapshot export --block HASH HASH.full> tezos-node snapshot import HASH.full> tezos-node run --rpc-addr 'localhost:8732'In addition, there are several ongoing efforts (e.g. see plebeia or Irmin2) to implement an efficient garbage collection mechanism that can run transparently, and provide a better, more optimised storage more generally.Special thanks to Arthur Breitman, Benjamin Canou, and Jacob Arluck for review.References:‘Introducing Snapshots and History Modes for the Tezos Node’ by Nomadic Labs.‘How to Quickly Boot a Tezos Node: a brief presentation of snapshots and history modes’ by Benjamin Canou.Spinning up a Tezos node in under a few minutes was originally published in tezos on Medium, where people are continuing the conversation by highlighting and responding to this story.


19. 05. 08

Introducing LIGO: a new sma...

A (self-aware) prototype of the LIGO logoIntroduction to LIGOIn order to implement Marigold, a layer 2 solution for Tezos, we built a language that would let us write complex, yet efficient, smart contracts. Thus, LIGO was born. LIGO is still in early-stage development, but we’re excited to give you a sneak peek.LIGO is a simple smart contract language designed for developing longer contracts than one would naturally write in Michelson. It is an imperative language that compiles down to clean Michelson code, featuring a Pascal-like syntax and a simple type system.LIGO is being developed by Nomadic Labs developers, Georges Dupéron and Christian Rinderknecht, and the Marigold Project.We are currently finishing the first prototype of LIGO. It features rich error messages, a small unit-testing framework and transpilation to Michelson. Over the next week, we will post a tutorial to install and play with it.For those who can’t wait to learn more, below is a sample of the code: an entry point to a crowdfunding contract.https://medium.com/media/0ffb093d9577450c83ee25b1bf08abed/hrefRoadmapOn top of the prototype, we are working on editor integration. We are starting with VS Code, but LIGO should easily enable support for Emacs and other popular editors.After we finish the prototype and basic editor integrations (syntax highlighting, type information and smart auto-completion), we’ll provide a user-guide, documentation for the compiler, as well as stabilize the command line interface.Nomadic Labs will then work on formal verification and improve tooling. Meanwhile, The Marigold Project will focus on writing its smart-contracts for Layer-2 scaling in LIGO.ContactIf you are interested in LIGO or Marigold, feel free to send an email at {contact@m-flower.io}Introducing LIGO: a new smart contract language for Tezos was originally published in tezos on Medium, where people are continuing the conversation by highlighting and responding to this story.


19. 03. 14

Tezos Athens

An overview of Athens, the first Tezos on-chain upgrade proposalsThe Parthenon in Athens, by Hans ReniersThis post summarizes today’s announcement from Nomadic Labs regarding Athens, the first on-chain Tezos upgrade proposals for Tezos arriving later this week. For a more technical explanation and changelog, please read Nomadic’s post directly.And of course, for a full overview of the Tezos governance mechanism, please check out “Amending Tezos” and the visualization below:https://medium.com/media/9b479c70411a976ffca1304765348199/hrefWhat’s in the Athens proposals?The proposed changes in the two Athens proposals are incremental:Athens Proposal 1: increase the gas limitThe gas limit was set conservatively at launch to protect the chain, with the idea that it could be increased via the amendment processThis proposal would increase the gas limit by allowing double the computation steps in each block while keeping the number of IOs performed in each block unchangedThis will make it incrementally easier to deploy smart contracts on Tezos, but maintains the gas limit at a conservative level as Nomadic Labs awaits more detailed benchmarking resultsNomadic Labs aims to propose further gas limit increases and a re-weighting based on ongoing benchmarking effortsAthens Proposal 2: increase the gas limit (see Proposal 1) AND reduce the roll size to 8,000 XTZ for Tezos Proof-of-StakeIn current Tezos consensus, a baker must have 10,000 XTZ to be randomly selected to propose or endorse a blockIn addition to increasing the gas limit, this amendment would reduce that threshold to 8,000 XTZ, incrementally lowering the barrier to entry to bakingPlease note that beyond these two incremental changes, the upgrade proposals also include minor fixes which do not significantly change the protocol, as described in the changelog.Benchmarking AthensNomadic states in their announcement post that they performed extensive testing to ensure the proposed protocols behave as intended and that the migration to Athens would not use an overly burdensome amount of time and disk space.For the gas costs, Nomadic based the new gas limits on a realistic mainnet context, with the new limits still set conservatively to ensure the network runs smoothly.Outside of the proposals, earlier this month Nomadic announced a new feature for Tezos nodes to improve storage via “Snapshots” and “History Modes”, as detailed in this blog post. As noted in today’s post, Nomadic hopes to integrate the snapshot feature into Tezos nodes within the next few weeks, improving storage performance.Nomadic tested the effects of roll size reduction for both kinds of nodes: full nodes adopting the snapshot feature (allowing faster sync and less storage) as well as nodes with a full context (i.e. “archive” nodes maintaining history of all past states).Regarding the proposals more broadly, Nomadic reports there is a one-time increase in disk space and time when the network migrates from the old protocol to the proposed Athens protocol.Based on these results, Nomadic deems any performance differences between the two proposals inconsequential:This cost only affects the migration block and has no impact on the subsequent operation of the network. In our opinion, the performance difference between the two protocol proposals is not significant.As implied, it is most important to evaluate proposals based on their longer-term economic impact (e.g. the cost of baking, barrier to entry, etc.) and operational impact (e.g. does the network continue running smoothly?), rather than a one-time cost of migration.Stakeholders will be able to evaluate this for themselves in the upcoming Zeronet testing initiative described in the “What comes next?” section below.InvoicingAs part of the upgrade, Nomadic will include a modest invoice for 100 XTZ:For this first update, we decided to include an example of invoicing, an on-chain way to fund the development of protocol proposals. During the migration, the account of the authors of a proposal can be funded by creating a certain amount of tez. In this case, we chose a symbolic value of 100ꜩ, enough to buy a round of drinks for the devs who worked on these proposals. In the future, we hope this mechanism can be used to fund the work of new teams and help increase decentralization.Why such modest, incremental changes?As described in Nomadic’s first “Meanwhile at Nomadic” post in January:The main goal [of the first proposals] is to prove that Tezos can carry out a successful update both technically and as a community. After all, we are all novices to the Tezos governance procedure and this aims to be a first step towards more substantial amendments.As stated, the goal is to demonstrate the mechanism first before advancing to shinier, more exciting upgrades which might lay over the horizon. A 3-month upgrade timeline enables Tezos to make exciting advances incrementally and a multi-stage voting mechanism aims to ensure the accountability of proposed changes to the network.Why “Athens”?In last week’s post, Nomadic Labs proposed a new naming convention for Tezos proposals:Our suggestion is to use city names, anglicised and in alphabetic order. Of course, in the future other entities will propose protocol upgrades, and it will be up to them to follow the convention or not. Yet, city names provide a wide set to choose from for each letter, with even a bit of room to express things.As a demonstration, “Athens” is a pretty obvious choice for this first voted upgrade, don’t you think?For illustration purposes, one might imagine future upgrades named “Brasília”, “Canberra”, “Delhi”, and so on.Note: the name “Athens” is not intended to bear any relation to Ethereum’s Constantinople hard fork also scheduled for later this week.What comes next?Protocol hashes, injection, and votingLater this week, Nomadic aims to provide the protocol hashes and inject the proposals. Bakers will then have roughly 3 weeks to upvote the Athens proposals, with the top-ranked proposal proceeding to a “Yes/No” exploratory vote for the subsequent 3 weeks.Voting instructionsNomadic will publish instructions for bakers on how to vote. The Tezos community should also expect to see detailed instructions from Obsidian Systems regarding how to use Ledger for voting.ZeronetThe Tezos Zeronet will be reset to offer a public test network with accelerated voting periods each lasting 56 hours long. Using the Zeronet, the entire voting procedure can be tested over 9 days, allowing stakeholders to analyze the activation of a new protocol safely within the test environment.Signal Your Preference and Join the Conversationtezvote.comTo signal your preference or to check your baker’s preference ahead of the Athens vote, please check out Stephen Andrews from TezTech’s’ TezVote, a recently launched vote signaling tool based on a simple Michelson contract.Upon announcement of the first Tezos proposals last month, preliminary discussions began on Kialo. It is worth noting that new evidence will become available once the proposals are injected and entities independent of Nomadic evaluate the proposals.Expect to see renewed discussion there and join the conversation!Tezos Athens was originally published in tezos on Medium, where people are continuing the conversation by highlighting and responding to this story.


19. 02. 25

Marigold: layer-2 scaling f...

An introduction to MarigoldCurrent blockchain networks offer strong guarantees of correctness and resistance to censorship. In exchange, they are slow and too expensive to run applications at scale. Marigold is a layer-2 project that trades off censorship resistance for speed and low fees, enabling applications that scale.Initially, the Marigold project focuses on a plasma-inspired implementation, but is not bound to any specific technology and can evolve to incorporate new advances from research. Marigold’s main focus is on a smooth developer and user experience rather than a commitment to any specific technology.How Marigold works: extending PlasmaMarigold is so far based on Plasma, a layer-2 solution where smart contracts are encoded to enable fraud proofs, allowing arbitrary computation to be safely executed off-chain. Vitalik Buterin and Joseph Poon introduced this idea in 2017.So far, Marigold implements the Minimal Viable Plasma, which is a form of Plasma restricted to simple transfers using a UTXO model.Dealing with mass exitsA common concern around Plasma design is avoiding the “mass exit” problem.Basically, the system unravels when the Layer-2 operator behaves unexpectedly (e.g. by withholding blocks or sending an invalid block) and users have to leave. In this scenario, funds are locked during the exit period and some users can lose their funds if they forget to leave or the base blockchain can become clogged as many users try to leave at once.In Marigold, the plan is to solve this mass exit problem via the following mechanisms:Delegation of UTXOs exit permissionUsers can assign their exit rights to another user (an exit-delegate)When an exit-delegate leaves, all of their delegators’ funds leave at the same timeA vote to move to another Marigold chain to minimize the interruption of service by an exit (with the goal of no interruption at all in the best case)Watching the chainAnother concern is that the system’s security relies on all users of Marigold watching the system for misbehavior. To avoid a free-rider problem, making an operation on Marigold will require solving a challenge, which amounts to checking that a few operations in the previous blocks are valid.Deploying MarigoldThe project’s main focus is on enabling developers from all horizons to start hacking and building on Marigold as soon as possible.Smart Contract Language for MarigoldGiven the public beta-version of Marigold will support arbitrary contracts (rather than only transfers), a smart-contract language tailored to developing applications on Marigold is in development.To avoid a steep learning curve, there will be support for multiple syntaxes and full integration with existing editors, such as Javascript in SublimeText and OCaml in Emacs.Easy deploymentA key design goal of Marigold is to make the deployment process as frictionless as possible for other developers. For users of contracts, making two signed API calls to a web-server is all that is needed, which makes it easy to build a Marigold-powered app, or a backend using Marigold for parts of its logic.Some work is also being done on interoperability between Marigold chains. This is important to compartmentalize failures between each application, yet retain the ability to use funds in all apps developed on Marigold. It also easily enables interoperability with other base-layer blockchains (e.g. Ethereum).Smart Contract Language for TezosBut first, project resources are dedicated to a new smart contract language for Tezos. What currently exists was sufficient for the Marigold prototype. However, the contracts needed for the full feature set described above require more because of their additional complexity.The futureRight now, the focus is on building a platform that enables scalable applications on Tezos. But after the platform is built, the project will move to add capabilities to the core of Marigold and building applications and a developer ecosystem on the platform.Improving the CoreOnce built, the project will integrate state-of-the-art research.The first direction is adding privacy features. This could be done through zk-snarks, mixing schemes, or homomorphic encryption (as seen in the AZTEC protocol).The second direction is making the protocol less interactive (ideally, non-interactive), so that users do not have to watch the chain at all. This could be done by adding an incentive layer, using state channels, or through recursive zk-snarks (a la Coda protocol).Attracting ApplicationsWe plan to attract a wide range of applications to the platform.On one hand, there is a concrete need to build solid blockchain applications that scale. Marigold is a strong fit for this category.On the other hand, there is a big emphasis on tooling, docs and examples. So that developers can hack on Marigold from the comfort of their own garage. This reduces the barriers to innovation, with the hope to encourage building on the platform through hackathons and bounty programs.ContactFor those interested in learning more about Marigold: {contact@mflower.io}. More details to come.Marigold: layer-2 scaling for Tezos was originally published in tezos on Medium, where people are continuing the conversation by highlighting and responding to this story.


19. 02. 04

A Tutorial Introduction to ...

Now that we know a little Michelson, let’s take a look at the Tezos blockchain, which is the “environment” in which our Michelson contracts are actually going to run.This is not going to be an exhaustive overview of Tezos; we’re going to focus on those aspects that are most relevant from the perspective of a Michelson programmer. We’re going to look at a few useful tools, such as the tezos-client program that is in the alphanet docker container we installed last chapter and an online blockchain explorer.These tools, like Tezos itself, are still immature and undergoing rapid development. For the most part, they employ the “info-dump” style of user interface, which works fine for e.g. a Tezos core developer, but can be very overwhelming to newcomers. For the purposes of this tutorial, we’re specifically interested in how to program in Michelson, so we can mostly abstract over a lot the detail exposed by the tooling that would be more relevant in other circumstances, such as if we wanted to run a baker. Some of these details will be covered again in greater depth in future chapters.For now, our goal is to gain a basic understanding of how to use the current Tezos tooling, with the goal, by the end of the next chapter, of running and interacting with a simple Michelson contract on the Tezos alphanet.In your terminal, in the directory where you installed the alphanet container from the last chapter, execute the following command:$ ./alphanet.sh headAssuming the node is running (if not, start it with ./alphanet.sh start), this should output something like:Warning:This is NOT the Tezos Mainnet.The node you are connecting to claims to be running on the Tezos Alphanet DEVELOPMENT NETWORK. Do NOT use your fundraiser keys on this network. Alphanet is a testing network, with free tokens.{ "protocol": "PsddFKi32cMJ2qPjf43Qv5GDWLDPZb3T3bF6fLKiF5HtvHNU7aP", "chain_id": "NetXgtSLGNJvNye", "hash": "BLe9jhCFStAkeYVpp4Czuh1Kp18qKUq1v5XWasbm1MiBMT1LGAs", "level": 27750, "proto": 1, "predecessor": "BLcZcNKP6ETkC9QRku27VFhSbWwFLqzjpEiMY4U6k5qJnfThVcn", "timestamp": "2018-12-13T12:53:28Z", "validation_pass": 4, "operations_hash": "LLoaaw91Q5k48SfBL96ttQe54WcUdn32BGKyNoDZ8sCA5KAEwJGMb", "fitness": [ "00", "00000000000bf429" ], "context": "CoWNoFZFhB2hGWhXv5VqEZgL6mS4UFtdJbYKrM7VY6Yt8MgZXiEp", "priority": 0, "proof_of_work_nonce": "00000003e24de8c8", "signature":"sigk66tvEvH2aYRTb3wurhqrRhw2SnGXuXreZii5Vg55mWgrDL98PJkXeDJ2Q8yZwJPLbTFPCUg9WT6bxYS6x5kBpqqK4Qa2" }Please ignore everything in this for the moment, except the following line:"hash": "BLe9jhCFStAkeYVpp4Czuh1Kp18qKUq1v5XWasbm1MiBMT1LGAs",Please copy the value on the right, as we will use it in a moment. Note that the actual value displayed in your terminal will almost certainly be different for you than what I’ve written down here. Please copy the value from your terminal.Now open tzcan.io’s alphanet block explorer in your browser, and in the search box paste the hash and hit enter.You should see something like this:This is the hash value of the block that your node thinks is currently the head of the Tezos alphanet blockchain.Look at the sections that sayPredecessor: BLcZcNKP6ETkC9QRku27VFhSbWwFLqzjpEiMY4U6k5qJnfThVcn Successor: BL5CZUh1CePUW4gwjKAJvyUsGrZwyExMwwjUPJGsHcC6vDWmU6jTo briefly review, a blockchain is, as the name suggests, a chain of blocks. Each block includes a hash of its predecessor block, which in turn includes a hash of its predecessor, and so on and so forth all the way back to the first (or “genesis”) block in the chain that has no predecessor. (Note only the predecessor hash is actually in the block, the successor hash is an out-of-band piece of information that tzScan has added for our convenience).You can take a look at the alphanet Genesis block here: https://alphanet.tzscan.io/0The reason each block includes the hash of its predecessor is to create a data structure that is prohibitively difficult to surreptitiously modify.For example, suppose I wanted to edit my copy of block BLe9jh... and add a transaction that credited one of my accounts with 1 billion tez, I could do that. But it would be obvious to everyone that I had tampered with the block, because the hash of the block would no longer match.All the information in the block (when serialized) is just a number. The hash of the block is just the output of a specific hash function on that number:Hash(serializedBlock) = BLe9jh...So if I add a transaction and change the block information, I change the serialized number represents that block, which will change the hash of the block. Since hash functions are designed to take negligible time and cost to run, if I try to send my tampered copy of the block to anyone else, they can easily recompute the hash function and discover that the hashes don’t match.Furthermore, because each block includes the hash of its predecessor, changing any block changes all the other blocks “downstream” of it. This means that as long as you and I agree on what the latest block in the chain (the head) is, we can agree on the whole history of the chain. (Agreeing on the head is problem solved by the consensus algorithm, which in Tezos is a variant of delegated proof-of-stake).This type of data structure, in general, is called a hash tree or a Merkle Tree. It’s important to emphasize, given the various abuses of the term, that all “blockchain” refers to is a hash tree whose nodes are blocks of transactions. It is a term in the same category as “key-value map”, or “linked-list”.Returning to our block explorer:We can see that block BLe9jh.. does not actually have any transactions in it. (your specific block may). This is because the Tezos Alphanet is designed for testing, so transactions are fairly rare and blocks are frequent (one every 30 seconds). Alphanet tez have negligible value and are in fact given away for free to anyone who wants them by a limitless faucet (which we will use later on). The Alphanet is not decentralized and is periodically reset from genesis every few weeks.Tezos has three parallel blockchains, called “Mainnet”, “Alphanet” and “Zeronet”Mainnet is where tez have real dollar value and where the network is decentralized. Zeronet is a bleeding edge test network used mainly by the core developers and is reset usually several times per day.To see a block with actual transactions go to the Mainnet block list.For this tutorial we’ll do most of our work on the Alphanet, although in a later chapter we’ll go through bootstrapping our own test network with a new genesis block.By the way, if you re-run:$ ./alphanet.sh headYou’ll notice that while you’ve been reading this section the head has updated.Now that we’ve covered enough context, we’re going to actually do a few things on the Alphanet.First, we’re going to need an identity, go to your terminal and run:$ ./alphanet.sh shellThis drops us inside the docker container, so we can directly execute commands on the tezos-node. Your prompt might change and you can run some commands to verify that you’re now inside a docker container:$ pwd /home/tezos ~ $ whoami tezos ~ $ ls -a . .. .ash_history .tezos-client .tezos-nodeYou can use <Ctrl-D> or$ exitto return to your regular prompt.$ ./alphanet shell $ tezos-node identity generateThis will take a short amount of time, so read on while it works.A Tezos identity consists of the following things:A peer_id that uniquely identifies us to the network. You can see a list of alphanet peers on tzScan's network pageA key-pair of public_key, secret_key that lets us securely communicate with other peers. E.g. we can use our secret key to generate transactions that other peers can verify came from us using our public key.A proof_of_work_stamp that shows that we did some amount of computational work while generating the identity. This is why the identity generate command takes some time, and is to prevent people from spamming the network by generating endless identities.You can read more about identity generation with$ tezos-node identity --helpNow that that’s done we can see the identity file generated by running:$ cat /home/tezos/.tezos-node/identity.json { "peer_id": "idtRhgUQFQcUFJLW5HXQbRcdYkaUr4", "public_key":"34a911ff9258d7c23b44844372a54c2a2a031d41e275e6a7d1251d1aeb95e207", "secret_key": xxxx "proof_of_work_stamp":"70e5ea8e85745a54f1a1d11b7c650e56f57f5c76243c072f"(Actually this .tezos-node/identity.json file is a dummy file, the docker container stores the real identity in /var/run/tezos/node/data/identity.json, but if you installed tezos from source it would be under .tezos-node)Remember to never ever ever post your secret key anywhere. If anyone other than you learns your secret key your whole identity is compromised. On the Alphanet it doesn’t really matter, but it’s a good idea to practice good operational-security even when it doesn’t matter so that it becomes a habit for when it does.The Tezos Alphanet faucet is a website run by the Tezos developers that lets us download a wallet file. Essentially, whenever the devs reset the alphanet, they include a bunch of funded accounts in the genesis block and then give the keys to those accounts away for free to anyone who wants to do some alphanet testing.Navigate to https://faucet.tzalpha.net/ and download the file.Now quit out of the alphanet docker container and cat the contents of that file:$ exit $ cat ~/Downloads/tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4.json { "mnemonic": [ "xxxx", "xxxx", "xxxx", "xxxx", "xxxxx "xxxx", "xxxx", "xxxx", "xxxx", "xxxx", "xxxx" "xxxx", "xxxx", "xxxx", "xxxx", ], "secret": "xxxx", "amount": "7489334243", "pkh": "tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4", "password": "xxxx" "email": "qaqjqdvr.xlicmfia@tezos.example.org" }%The two lines of relevance for us are:"amount": "7489334243", "pkh": "tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4",This wallet file, like the identity file, has a cryptographic secret key. After activating the account listed in this file, the way you’re going to tell the network that you want to make a transfer is by broadcasting a transaction message (signed by this secret key) over the peer-to-peer network, using the p2p identity we generated earlier. Other peers can verify the correctness of transactions (whether we have enough tez to make a transfer) by validating our signature with our accounts public-key, which is the “address” of the account, as well as by looking up our balance in the blockchain.Now let’s activate the account, giving it the local nickname alice:$ ./alphanet client activate account alice with "container:/home/jcb/Downloads/tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4.json"This should output:Node is bootstrapped, ready for injecting operations. Operation successfully injected in the node. Operation hash: onotiUDrveZX1NRt39zQmPxVbVkxS2qfpM5gucFTV8BvvfPZoRB Waiting for the operation to be included... Operation found in block: BM5RPwciV64Bz5nG3FbYY6xusrFt2j6EHTBrA7Hhye9fzWUhMK1 (pass: 2, offset: 0) This sequence of operations was run: Genesis account activation: Account: tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4 Balance updates: tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4 ... +ꜩ7489.334243The operation has only been included 0 blocks ago. We recommend to wait more. Use command tezos-client wait for onotiUDrveZX1NRt39zQmPxVbVkxS2qfpM5gucFTV8BvvfPZoRB to be included --confirmations 30 and/or an external block explorer. Account alice (tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4) activated with ꜩ7489.334243.Let’s open up tzScan and take a look at block BM5RPwciV64Bz5nG3FbYY6xusrFt2j6EHTBrA7Hhye9fzWUhMK1 which includes this activation:And now if we click on the account activation, we should see:with the balance!(It can take up to a few minutes for transactions to appear on tzScan, so if you don’t see your transaction just sit tight for a bit while more blocks get confirmed and try again.)Now lets generate a brand new account called “bob” with no balance of tez:$ ./alphanet.sh client gen keys bobThis should just output the Alphanet warning, but we can go inside the docker container and see the accounts we’ve generated or activated with$ ./alphanet.sh shell $ cat /var/run/tezos/client/public_key_hashs [ { "name": "bob", "value": "tz1QCUKL2YZuGLSdTesXtVHJB8zRcG6XTz8f" }, { "name": "alice", "value": "tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4" } ]All the internal stored client data is in /var/run/tezos/client in the docker container, and in .tezos-client if you installed from source.The client provides a better interface to the internal stored data, however:$ ./alphanet.sh client list known addressesbob: tz1QCUKL2YZuGLSdTesXtVHJB8zRcG6XTz8f (unencrypted sk known) alice: tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4 (unencrypted sk known)Lets check the balances for alice and bob:$ ./alphanet.sh client get balance for alice 7489.334243 ꜩ$ ./alphanet.sh client get balance for bob 0 ꜩLet’s transfer 420 tokens to bob from alice:$ ./alphanet.sh client transfer 420.5 from alice to bob --fee 0.5Fatal error: The operation will burn ꜩ0.257 which is higher than the configured burn cap (ꜩ0). Use `--burn-cap 0.257` to emit this operation.There’s burn-cap setting in the client to prevent us from accidentally sending a transaction that would burn more tez than want:Λ ➜ ./alphanet.sh client transfer 420.5 from alice to bob --fee 0.5 --burn-cap 0.257Node is bootstrapped, ready for injecting operations. Estimated gas: 10100 units (will add 100 for safety) Estimated storage: 257 bytes added (will add 20 for safety) Operation successfully injected in the node. Operation hash: opXPyuAXx2yWoReQvWF6tra4aREqS2NgCBQNDtyo4rtZJAuizrM Waiting for the operation to be included... Operation found in block: BMRY5jRXjTtU2LeVoWFgSo9D7BU4eFqNB6UCSeZ6neWZhu5AXPt (pass: 3, offset: 0)This sequence of operations was run:Manager signed operations: From: tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4 Fee to the baker: ꜩ0 Expected counter: 5807 Gas limit: 10000 Storage limit: 0 bytes Revelation of manager public key: Contract: tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4 Key: edpkuS9a1795Cwwrstx6B6Q3Bugo3CKJ2NxtohxnjEaQGiJkWTD5YE This revelation was successfully applied Consumed gas: 10000Manager signed operations: From: tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4 Fee to the baker: ꜩ0.5 Expected counter: 5808 Gas limit: 10200 Storage limit: 277 bytesBalance updates: tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4 ... -ꜩ0.5 fees(tz3NdTPb3Ax2rVW2Kq9QEdzfYFkRwhrQRPhX,14) ........... +ꜩ0.5 Transaction: Amount: ꜩ420.5 From: tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4 To: tz1QCUKL2YZuGLSdTesXtVHJB8zRcG6XTz8f This transaction was successfully applied Consumed gas: 10100Balance updates: tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4 ... -ꜩ420.5 tz1QCUKL2YZuGLSdTesXtVHJB8zRcG6XTz8f ... +ꜩ420.5 tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4 ... -ꜩ0.257The operation has only been included 0 blocks ago. We recommend to wait more.Use command tezos-client wait for opXPyuAXx2yWoReQvWF6tra4aREqS2NgCBQNDtyo4rtZJAuizrM to be included --confirmations 30 and/or an external block explorer.This prints a nice receipt for us detailing exactly what happened to our tez.Let’s take a look at bob, or tz1QCUKL2YZuGLSdTesXtVHJB8zRcG6XTz8f on tzScan:But wait, why is it 420.5 tez? Didn't we pay a fee of 0.5 tez? Take a look at the balance update sections of the receipt again (I've added notes for which address is alice and which is bob)... Balance updates: alice tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4 ....... -ꜩ0.5 fees(tz3NdTPb3Ax2rVW2Kq9QEdzfYFkRwhrQRPhX,14) .... +ꜩ0.5 ... Balance updates: alice tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4 ... -ꜩ420.5 bob tz1QCUKL2YZuGLSdTesXtVHJB8zRcG6XTz8f ......+ꜩ420.5 alice tz1M1tuK4BM53S2niKvQDn6SbACiVk6zbjx4 ... -ꜩ0.257The fees came out of alices account separately from the transaction. So the total amount alice payed was -ꜩ421.257This concludes our chapter on basic Tezos operations. Next chapter, we’ll integrate what we’ve learned here with the Michelson we learned in chapter I to actually run a Michelson contract live on the Tezos blockchain!Exercise 1: The Tezos client comes with a manual, which you can access with$ ./alphanet.sh client manThis will by default output the manual formatted with colors. Use the manual to figure out what options to pass to the client man command to turn the colors off.The Unix tools grep and less may be useful here, and there is also a copy on the web: http://tezos.gitlab.io/alphanet/api/cli-commands.htmlExercise 2: Go into the docker container shell (as we described earlier) and run$ tezos-admin-client-p2p statScroll to the section that says “Known Peers”.In your browser, open tzScan’s alphanet Network Stats page.Find a peer ID that appears in both lists.Exercise 3: Find the hashes of the Mainnet, Alphanet and Zeronet genesis blocks. How do they differ?Exercise 4: Generate four new addresses in your client called eenie, meenie, meinie and mo. Conduct transfers to each address such that eenie has exactly 1 tez, meenie has exactly 2 tez, meinie has exactly 3 and mo has exactly 4.Originally published at gist.github.com on December 17, 2018.A Tutorial Introduction to Michelson & Tezos, Part II: Hello Tezos was originally published in tezos on Medium, where people are continuing the conversation by highlighting and responding to this story.


18. 12. 17

A Tutorial Introduction to ...

Michelson is the smart contract language of the Tezos blockchain. Roughly speaking, Michelson is to Tezos as the Ethereum Virtual Machine is to Ethereum. Both languages are stack-based, which means that computation is performed by mutating a sequence of data elements (the stack) according to some sequence of instructions (the program).The most notable difference between Michelson and EVM is that Michelson is written in a human-legible text format, whereas EVM operations are represented as bytes. For example, if you look up the opcode table for the EVM you’ll see that the opcode 01 takes two numbers (off the top of the stack) and adds them together. The equivalent operation in Michelson is written as ADD.(To be fair, the addition opcode 01 in the EVM has ADD as an intermediate mnemonic representation)In the above image, we have a stack that we can write out as20 : 7 : 13 : 45 : []where : is our element separator and [] indicates the bottom of the stack.In the illustration we apply the operation ADD to the stack, which has the following definition:ADD / a : b : S => (a + b) : SIn plain English, this definition says “The ADD operation removes the top two elements of the stack (a and b in the definition) and then puts the element (a + b) back onto the top of the stack:ADD / 20 : 7 : 13 : 45 : [] => (20 + 7) : 13 : 45 : [] => 27 : 13 : 45 : []All computation with Michelson works similarly based on this process of stack mutation. We used ADD in the above example, but we could also mutate the stack with other arithmetic operations like subtraction or multiplication, or logical operations like NOT, AND, OR. We can directly manipulate the stack by explicitly pushing data onto it, or by swapping around or duplicating elements. We have control flow structures like LOOP or IF. We can perform some cryptographic operations like hashing or checking signatures, and we can interact with the blockchain by initiating token transfers or creating accounts. Michelson has lot of different operations.The second major difference between Michelson and EVM, is that Michelson data elements are typed.Broadly speaking, a type is a piece of information that constrains the possible things that can be done with a given data value.If the value 1 has the type int (for integer), then we know that we can safely perform numerical addition on it, but that we can't safely perform list indexing.For the value "foobar" with type string, the situation is reversed. Adding a number to a list 1 + "foobar" is not well-defined, because addition is an operation on integers (in most languages, some languages overload the + operator to mean numerical addition when its arguments are numbers and concatenation when its arguments are strings)Types are useful because they allow the Michelson interpreter to exclude programs that may have problematic behaviour. For example, with the natural number type, nat, attempting to subtract a larger nat from a smaller nat like 4 - 5 will result in an error. The programmer then can determine during testing whether this error is the result of an undesired operation, incorrect arguments, or whether the type signature of the values ought to be changed. The crucial thing is that this error occurred early on and prevented the program from running at all, rather than for the possible bug to slip past testing unnoticed only to cause issues later on in production.Generally speaking, types allow the programmer to communicate their intentions in more detail to the machine, and allows the machine to communicate to the programmer when execution deviates from those intentions.Okay, now that we’ve covered a little bit of the theory of how Michelson works, let’s get our hands dirty with some code.The easiest way to play with Michelson is to install the Tezos client from using docker. In your terminal type the following commands:$ wget https://gitlab.com/tezos/tezos/raw/alphanet/scripts/alphanet.sh$ chmod +x ./alphanet.sh$ ./alphanet.sh startThis should spit out a bunch of output that you can mostly ignore for now. The important thing is that packaged within the Tezos client is a Michelson runtime we can use to test our programs.Alternatively, you can build Tezos from source by following the instructions in the Tezos DocsOpen up your favorite editor and write the following program helloTezos.tz in the same directory you put the alphanet.sh script.# helloTezos.tzparameter unit; storage string; code {DROP; PUSH string "Hello Tezos!"; NIL operation; PAIR;};First we’re going to check that the script is well-typed:$ ./alphanet.sh client typecheck script container:helloTezos.tzWe can see more information emitted by the typechecker by adding the --details flag:$ ./alphanet.sh client typecheck script container:helloTezos.tz --detailsThis program should typecheck, but if it doesn’t, possible reasons are if the file was copied incorrectly, or if there have been breaking changes to the Michelson semantics since this document was published.Now that we know the program typechecks, we’re going to run it. The command for telling the tezos client to run a Michelson program (in a sandbox) is:$ ./alphanet.sh client run script <path> on storage <data> and input <data>where <path> is the path to the program source (since we're using docker this will be prepended with container:), and <data> is some Michelson value.We’ll go over what storage and input mean below. For now, try running:$ ./alphanet.sh client run script container:helloTezos.tz on storage '""' and input UnitThis should return:storage "Hello Tezos!" emitted operationsCongratulations, you’ve just run your first smart contract in Michelson!Now let’s get into the details of how the contract works:All Michelson smart contracts are functions that take two arguments, an input parameter and a storage value, and return a pair of a list of operations and a storage value. The storage value is effectively a return value, and the list of operations are like a continuation, if, for example, the contract was called by another contract.There are many different ways to notate types signatures but here’s what the Michelson type signature of a contract looks like:lambda (pair 'parameter 'storage) (pair (list operation) 'storage)Personally, I prefer type notation more like Haskell’s, but both signatures are equivalent:contract :: (Parameter p, Storage s) -> ([Operation], Storage s)Let’s take another look at helloTezos.tz:# helloTezos.tzparameter unit; storage string; code {DROP; PUSH string "Hello Tezos!"; NIL operation; PAIR;};The parameter unit and storage string lines specify the types of the contract's two arguments. If we concretize the above signature for the general type of Michelson contracts, with 'parameter as unit and 'storage as string, we get the type of our specific helloTezos.tz contract:lambda (pair unit string) (pair (list operation) string)The initial stack of a Michelson contract is its argument pair (pair 'parameter 'storage) so helloTezos.tz starts with a stack of type::: (pair unit string) : []At the command line we ran$ ./alphanet.sh client run script container:helloTezos.tz on storage '""' and input Unit'""' is the command-line syntax for "", the empty string and Unit is the data constructor of the single inhabitant of the unit type. Be advised that input and parameter are synonymous here. So our initial stack has the concrete value:(Pair Unit "") : []which has type:: (pair unit string) : []The distinction between Pair and pair is that Pair is a data constructor and pair is a type. Data constructors in Michelson begin with an initial capital, whereas types are all lowercase.Now we have our initial value, and our return type, we can think about the the execution of our contract as a sequence of operations that transform our initial value into a return value that matches our return type.In other words, we started with(Pair Unit "") : [] :: (pair unit string) : []and we want to end up with??? :: (pair (list operation) string) : []Fortunately, our contract is pretty short at only 4 operations, so we can walk through the steps of this transformation here. The operations are written after the code heading in helloTezos.tz:# helloTezos.tz code {DROP; PUSH string "Hello Tezos!"; NIL operation; PAIR;};If we write down this operation sequence and the initial values and types from the previous section, we get the full state of our Michelson stack machine:STATE code DROP; PUSH string "Hello Tezos!"; NIL operation; PAIR; stack (Pair Unit "") : [] type :: (pair unit string) : []The DROP operation removes (or "drops") the top element of the stack and has the following definition (slightly rearranged from the Michelson spec)code DROP stack _ : S => S type :: _ : 'A -> 'Awhere _ is a wildcard matching any operations, values, or typesApplying this to our state, our new state is:STATE code PUSH string "Hello Tezos!"; NIL operation; PAIR; stack [] type :: []The PUSH operation adds a value with a certain type onto the top of the stack and has the following definition:code PUSH 'a (x :: 'a) stack S => x : S type 'A -> 'a : 'AOur concrete instruction is PUSH string "Hello Tezos!", so the transformation is concretized as:code PUSH string ("Hello Tezos!" :: string) stack S => "Hello Tezos!" : S type 'A -> string : 'Awhich when applied gives us a new state:STATE code NIL operation; PAIR; stack "Hello Tezos!" : [] type :: string : []The NIL operation adds an empty list of a certain type onto the top of the stack and has the following definition:code NIL 'a stack S => {} : S type 'A -> list 'a : 'Awhich when applied gives us a new state:STATE code PAIR; stack {} : "Hello Tezos!" : [] type :: list operation : string : []The PAIR operation removes the top two elements of the stack, makes a pair of them, and pushes the pair onto the stack. It has the following definition:code PAIR stack a : b : S => (Pair a b) : S type 'a : 'b : 'A -> pair 'a 'b : 'Awhich when applied gives us a new state:STATE code stack (Pair {} "Hello Tezos!") : [] type :: pair (list operation) string : []We are now out of operations, and our stack has type pair (list operation) string : [] which is exactly what we wanted. Since the type matches our expected return type, the contract returns the values in our (pair 'operations 'storage):storage "Hello Tezos!" emitted operationsThis concludes Part I of our Michelson tutorial. You should now knowthe basics of how a stack machine workshow to install the Tezos clienthow to write and execute a simple michelson contractwhat Michelson types, values and operations are and some simple examples of each oneIn Part II, we will write more contracts and go through their execution (although with less rigor), introducing more operations, types and data constructors.Exercise 1: Modify our helloTezos.tz file to output "Hello World!" instead of "Hello Tezos. Call this file helloWorld.tzExercise 2: Now modify our helloTezos.tz file to take a string argument as input and output "Hello <input>". Call this file helloInput.tz You will need to know two additional operations to do this:code CAR # select left-hand of pair stack (Pair a _) : S => a : Stype pair 'a 'b : 'A -> 'a : 'Acode CONCAT # string concatenate stack a : b => a ^ b : S type string : string : 'A -> string: 'A where a ^ b concatenates the end of a to the beginning of bExercise 3: Do the same thing as exercise 2, except now the contract takes a unit as its input parameter, and outputs "Hello " concatenated to its initial storage. So running$./alphanet.sh client run script container:hellotezos.tz on storage '"bar"' and input 'Unit'should output “Hello bar”. Call this file helloStorage.tzYou will need to know one additional operation:code CDR # select right-hand of pair stack (Pair _ b) : S => b : S type pair 'a 'b : 'A -> 'b : 'AExercise 4: Write a contract that concatenates an input string and a storage string and ouputs "Hello <input><storage>". call this filehelloInputAndStorage.tzYou will need to know:code DUP # Duplicate the top of the stackstack x : S => x : x : Stype :: 'a : 'A -> 'a : 'a : 'Acode DIP ops # Runs code protecting the top of the stackstack x : S => x : S' where ops / S => S' type :: 'b : 'A -> 'b : 'C iff ops :: [ 'A -> 'C ]You could also use SWAP instead of DIPSWAP # Exchange the top two elements of the stackstack x : y : S => y : x : S type :: 'a : 'b : 'A -> 'b : 'a : 'AA Tutorial Introduction to Michelson & Tezos, Part I: Hello Michelson was originally published in tezos on Medium, where people are continuing the conversation by highlighting and responding to this story.


18. 12. 17

Amending Tezos:

Amending TezosTraversing the amendment processBackgroundTezos is a self-amending blockchain network which incorporates a formal, on-chain mechanism for proposing, selecting, testing, and activating protocol upgrades without the need to hard fork.In this post, I describe how the Tezos amendment process works in practice and propose several ways to improve it in the near-term. Deeper questions, like splitting voting rights from consensus, or how amendments should be funded on-chain are outside the scope of this post, but important topics for future consideration.This piece assumes a basic knowledge of Tezos baking. I recommend reading “It’s a baker’s life for me” and the Tezos proof-of-stake documentation to get started.* I use the expression “amendment process” instead of “election cycle” to avoid confusion with “cycles” of baking.Understanding the Tezos amendment processThe amendment process can be broken into four discrete periods: the Proposal Period, the Exploration or “Testing” Vote Period, the Testing Period, and the Promotion Vote Period. Each of these four periods lasts eight baking cycles (i.e. 32,768 blocks or roughly 22 days, 18 hours), comprising almost exactly three months from proposal to activation.As summarized in the flowchart diagram below, any failure to proceed to the subsequent period reverts the network back to a Proposal Period. In other words, failure to proceed restarts the entire amendment process.This is precisely what has been happening since the Tezos genesis block was adopted by the community in June. In the absence of any proposals, a new proposal period has restarted every eight cycles since Block 1.So how does it work?Proposal PeriodThe Tezos amendment process begins with the Proposal Period, during which bakers can submit proposals on-chain via the proposal operation, which takes “source”, “period” and “proposals hash” as parameters. The “source” is the baker who submits the proposal operation, the “period” specifies the specific proposal period in which the proposal was submitted, and the “proposals hash” is the hash of the tarball of concatenated .ml/.mli source files.Bakers may submit up to 20 proposals in each Proposal Period. When submitting a proposal, the baker is also submitting a vote for that proposal, equivalent to the number of rolls in its staking balance at the start of the period.For those wanting to follow along, Tzscan.io (and hopefully other Tezos block explorers) allows you to watch incoming proposals.Other bakers can then vote on proposals by submitting proposal operations of their own. As described in the white paper, the Proposal Period vote is done via approval voting, meaning each baker may vote once on up to 20 proposals. Think of it as a form of “upvoting.”At the end of the Proposal Period, the network counts the proposal votes and the most-upvoted proposal proceeds to the Exploration Vote Period. If no proposals have been submitted or if there is a tie between proposals, a new Proposal Period begins.2. Exploration Vote Period (known as “Testing Vote” in the current protocol)In the Exploration Vote Period, bakers may vote on the top-ranked proposal from the previous Proposal Period.Voting is done on-chain via the Ballot Operation, which takes “source,” “period_n,” “proposal,” and “ballot.” The “source” is the baker, “period_n” is the specific voting period in which the operation was submitted, “proposal” specifies the proposal, and “ballot” specifies the baker’s vote, either “Yay,” “Nay,” and “Abstain.”As in the Proposal Period, a baker’s vote is based on the number of rolls in its staking balance at the beginning of the Exploration Vote Period. Each baker may send a ballot operation only once during the voting period.At the end of eight cycles, the network counts the votes. If voting participation (the total of “Yays,” “Nays,” and “Abstains”) meets the quorum (explained below) and an 80% supermajority of non-abstaining bakers approves, the proposal proceeds to the Testing Period.If the quorum or the 80% supermajority are not met, the amendment process reverts to the beginning of the Proposal Period.A notable difference from the Proposal Period is that after the Exploration Vote Period, the quorum is updated as follows where Q_t is the previous quorum and q_t is the total participation:This adjusts the quorum to match an exponential moving average of the past participation rate.In the genesis block, the quorum began at 80% and will remain at 80% until the end of the first Exploration Vote Period.3. Testing PeriodIf a proposal is approved by a supermajority in the Exploration Vote Period, the Testing Period (8 cycles) begins with a testnet fork that runs parallel to the main Tezos chain for 48 hours before terminating. This 48-hour constant has been set conservatively in order to reduce the risk of the network perceiving the testnet fork as the main chain.Just as described in the 2014 white paper, proposals have access to a small standard library, but are sandboxed and can not make any system calls.The purpose of the Testing Period is to evaluate whether a proposal is a worthy amendment to the protocol.The testnet fork ensures the upgrade does not corrupt the context and that, should the upgrade be adopted, the network would continue making valid state transitions. However, 48 hours of testing by itself is decidedly too short to determine whether a proposal would be a worthwhile and safe amendment. In particular, it can maintain liveness longer than 48 hours and does not contain security vulnerabilities). As a result, a testnet matching the amendment proposal is likely to run off-chain for the remaining ~7.3 cycles of the Testing Period, allowing stakeholders to evaluate and discuss the amendment as gain better knowledge of its properties.4. Promotion Vote PeriodAt the end of the Testing Period, the Promotion Vote Period begins. In this period, the network decides whether to adopt the amendment based on off-chain discussions and its behavior during the Testing Period.As in the Exploration Vote Period, bakers submit their votes using the ballot operation, with their votes weighted proportionally to the number of rolls in their staking balance at the beginning of the Promotion Vote Period. As in the Exploration Vote Period, each baker may send only one ballot operation during this period.At the end of the Promotion Vote Period, the network counts the number of votes. If the participation rate reaches the minimum quorum and an 80% supermajority of non-abstaining bakers votes “Yay,” then the proposal is activated as the new mainnet.Otherwise, the process once more reverts back to the Proposal Period. The minimum quorum is updated based on the participation rate using the same formula which was used at the end of the Exploration Vote Period:Once the amended protocol is activated, a new Proposal Period begins and the amendment process begins anew.Improving the Tezos Amendment ProcessAs it stands, the current Tezos amendment process is designed with a simple, but effective mechanism for amending both the protocol and the amendment process itself.The current design is well-suited to bootstrapping improvements to Tezos in its early days, but below are five glaring opportunities for improvement in the current on-chain implementation.There are also opportunities to encourage healthy coordination off-chain. Two examples that come to mind are incentivized testnets (a la Cosmos’ Game of Stakes) and a discussion forum based on reputation/stake), but these fall outside the scope of this piece.Lengthen the proposal period and introduce proposal feesLengthening the proposal period to 12 or 16 cycles would allow more time to debate and coordinate around proposals. Furthermore, a requirement that proposals be submitted within the first 8 cycles would ensure sufficient time for discussion before the amendment proceeds to an Exploration Vote Period. This requirement would also prevent proposers from sniping the end of a Proposal Period in which no proposals or only weakly upvoted proposals had been submitted.Proposal quality also represents a modest risk in the current Tezos network, particularly if some bakers face a coordination cost in distinguishing legitimate proposals from malicious or mediocre ones. Ultimately, it should be inexpensive to vote on proposals, but submitting one should incur a cost to deter spam and frivolous proposals.Introducing an upfront proposal fee of say, 500 xtz seems like a simple yet reasonable precaution that reduces the risk of proposal spam in the early days of the network.Alternatively, a time-locked deposit could be priced at a higher level (e.g. 2,500 xtz) and returned to the proposer if the proposal is upvoted by at least 10% of the voting weight in the Proposal Period.2. Evaluate voting weight at the end of voting periods, rather than the beginningBecause bakers’ staking balances are counted at the start of each voting period, delegators cannot change their delegation once voting has begun. This forces delegators to trust delegates to commit truthfully to the votes they signaled before the start of the period.Evaluating a voter’s staking balance at the end as opposed to the beginning of the voting period would allow delegators to move their stake once they’ve seen how their delegate voted. At least for now, this also encourages delegates to create one delegation address for those preferring “Yay” for a given proposal and another for “Nay.” This would allow delegators to keep their preferred delegate(s) but still hold influence in the amendment process.At first this may seem counterintuitive, because delegators are used to waiting 7 cycles before their delegated tokens actually provide baking rights. In reality, rolls are counted in real time when delegated, even though they affect baking rights only after 7 cycles.That said, switching also incurs other meaningful transaction costs. There are search costs associated with finding a new delegate who votes as desired, but who does not tradeoff payout structure or reliability. Another concern is that a delegate could try to retaliate against delegators who switch during a voting period. One possible solution would be to enable delegators to secretly override their delegate’s vote.3. Longer testnet forks and a longer testing period overallLengthening the overall Testing Period to 12 cycles from 8 would provide stakeholders more time and data by which to evaluate and discuss the properties of a given proposal.That said a 2-day testnet fork may not provide a long enough period to evaluate the persistence of the amended protocol. Conducting the testnet fork for one week could incrementally improve the realism of the on-chain test fork.Proposals will have been tested in off-chain environments long before the Testing Period and the Testing Period may evolve into more of an “Evaluation period”.Another possibility would be to eventually create a testnet that’s permissioned on-chain via a DAO or elected council. The decision-making latitude of this council could be narrowly specified: the council’s capability could be limited to delaying advancement to the Promotion Vote Period by a fixed number of cycles for the express purpose of allowing more time for further evaluation. By contrast, a more aggressive approach would entail the council voting to advance the proposal to a Promotion Vote Period at predefined intervals (e.g. at 8 cycles or 16 cycles).4. Quorum floorThe Tezos quorum adjustment mechanism is a simple, yet powerful tool to avoid stagnation as a result of low stakeholder participation and lost coins. However, many successive Voting Periods (e.g. 1 year) with low participation could drive the quorum to low levels, allowing proposals to pass without much support. Although malfeasance can be blocked by mobilizing “nay” votes, setting a minimum quorum may be worthwhile as an additional protection.One possibility would be for the supermajority approval threshold in the Voting Periods to adjust based on the participation rate. Under this model, the network would require an 80% supermajority to vote “Yay” at a 60% participation rate and a 90% supermajority at a 50% participation rate.Alternatively, it’s also possible to require the quorum to be greater than the average participation rate. For instance:Following this formula, if the average participation rate were 0%, the network would maintain a floor of 20%. If the average participation rate were 50%, then the minimum quorum would be 60%, and if the average participation rate were 80%, then the minimum quorum would be 84%.5. Delay activation of the amended protocolThe current Tezos protocol activates amendments directly at the end of the Promotion Vote period. However, it would be prudent to delay activation by a predefined number of baking cycles to ensure that the network is prepared for the new protocol (particularly if the protocol incorporates changes to the consensus itself). This could also, conceivably, delay the start of the next Proposal Period as a buffer period to allow bakers to adjust to the workings of a new protocol.Amendment RPCsThis week’s Proto3 update has paved the way by adding a host of RPCs to support the amendment process. This will allow the Tezos community to interact with proposals, check the quorum, see the number of ballots cast, and refer to other important amendment-related data mentioned throughout this piece.ConclusionAs detailed, Tezos implements a multi-stage amendment process that allows stakeholders to formally propose, select, test, and activate upgrades to the protocol on-chain.But we should remember, first and foremost, that blockchain governance remains a nascent field. There is still little in the way of directly analogous experience to draw upon.This demands that we wade in slowly and take great caution. Incentivizing proposal quality, encouraging greater delegate accountability, and providing a longer testing period seem reasonable first steps to improve the amendment process. But these are merely places to start.What is most important is that we learn from our early experiences with the amendment process. And even with early success, we should be wary of the existing system’s limitations, particularly its reliance on voting, over the longer term. It is critical to explore complementary mechanisms: especially, futarchy, programmatic constitutionalism, and on-chain councils.After all, blockchain governance should not be merely about the “next” upgrade, but rather about creating internet-native institutions that are built to last, ones that can be adopted sustainably by hundreds of millions, if not billions of users some day. Introducing the Tezos amendment process aims to be a step towards that goal.Resources:Tezos White PaperTezos Position PaperProto3 update documentation (includes amendment RPCs)Amending Tezos: was originally published in tezos on Medium, where people are continuing the conversation by highlighting and responding to this story.


18. 11. 29

A few directions to improve...

In which I outline, for different categories, what seems to me as reasonable, immediate, directions for improving Tezos. The emphasis is on relatively low hanging fruits, nothing earth shattering, just pragmatic, steady, incremental improvements.Tooling, higher-level languages, second layer scaling solutions, and other elements living outside of the protocol are undoubtedly important, but out of scope for the sake of this post.NodeUsers running nodes improve the security of the network by making it harder for a malicious coalition to create social consensus around a departure from the protocol. Thus, it’s important that the requirement for running a node remain reasonable. At a minimum, they should be bounded, which means nodes should implement garbage collection for past states and past blocks. Keeping a full history of blocks is laudable, some people should do it, some people will doubtlessly do it, but it doesn’t have to be done by everyone. It certainly shouldn’t be held up as a sine qua non that would deter people from running nodes.Another kind of nodeThe node should also be able to synchronize directly by downloading the context from a known point. Implementing a light client that relies on a known context hash but requires Merkle proofs when it queries parts of the context would also be of interest, but I’m departing from protocol related matters here.Consensus algorithmThe “liquid” delegation model with bonding seems like a successful recipe so far, I think it’s important to preserve it. Most of the proof-of-stake machinery in Tezos is roll-tracking and randomness generation. This ends up producing periodic random seeds and a set of 80,000 or so rolls. The combination of the two is a blank canvas for consensus.Yay, baking!Better randomnessAs I’ve suggested before the entropy generation should be hardened. There’s an implementation of PVSS in Tezos which can do that, by requiring a large coalition of malicious users to affect randomness. It’s here, I think it’s worth including. Another technique, which is both more powerful and lighter weight is to use a VDF to sufficiently “delay” the generation of the random seed as to make manipulation impossible. Chia network recently championed two elegant (and surprisingly elementary) techniques for instantiating VDF. The downside is that these require computation in a group of unknown order.Chia proposes two ways of building such groups: using the residuals modulo a product of two unknown primes or using a more exotic group of binary quadratic form. The former is a well-studied problem but requires a trusted setup, the latter doesn’t require a trusted setup but hasn’t been studied as thoroughly.I’d for one recommend using both and hashing the concatenated outputs to form a seed. For the RSA group, using the existing 2048 bits RSA Challenge number saves one the trouble of running an MPC ceremony. If this VDF is implemented in Tezos, the use of PVSS or even a commit-reveal scheme becomes technically unnecessary but, in the tradition of belts and suspenders, I would say it can’t hurt.Better consensusSynchronicity assumptions are icky (unless the times are on the order of hours) and using a set number of validators doesn’t work well with the liquid POS model. This leaves essentially one option, which many seem to be converging upon: sortition and BFT agreement (e.g. DFinity, Algorand though both intend to do cleverer stuff in addition). Note that BFT agreement is a criterion for accepting blocks, namely that 2/3+ of the endorsers endorse a block. For endorsers to succeed in doing so, they need to reach Byzantine agreement. The strategy they use can vary!Tendermint’s a fine algorithm I think it’s likely the best starting point. Note however that Avalanche — or any other agreement BFT agreement strategy — could be used instead, without changing the Tezos protocol itself.From the outside, the protocol would look very similar to the current one: block slots with priority lists, endorsers (a few hundred endorsers per block instead of 32). The difference is that the protocol would require the bakers to (probabilistically) achieve Byzantine fault tolerance on each block before proceeding. This seems like a Good Thing and preferable to over-thinking a chain-based approach.PrivacySealed enveloppes are better than postcardsCrypto-currencies typically require transactions to be broadcast publicly to the entire world, which is obviously problematic for privacy. No business wants the entirety of its transactions known to its competitors (and of course privacy doesn’t dispense you — or prevent you — from having to open your books should you be required to).Several solutions have been proposed and implemented, each with different trade-offs in terms of complexity, scalability, privacy, etc. With the new Sapling release, I lean towards Zcash currently offering the best trade-off. The transactions are concise and provide the maximum amount of privacy achievable. The necessity of a trusted setup is a sore point, but it is mitigated by the large number of participants in the ceremony, and the possibility of “turn-stiling” the private notes by preventing more coins from coming out than coins coming in. The easiest path is binding to Sapling’s Rust library.In Zcash coins are turned into blinded commitments placed in a Merkle tree (which I insist should be called a dazzle). These commitments can be transacted using zero knowledge proofs. While it would be possible, in principle, to have these hidden commitments participate in proof-of-stake, it seems hard to achieve and it’s unlikely to be fruitful as an immediate area of focus. Note that, unfortunately, both “turn-stiling” the commitments and not allowing them to participate in the proof-of-stake inflation are detrimental to the size of the anonymity set since they incentivize getting funds out quickly. Also bear in mind that it would be possible to offer this circuit as a primitive in smart-contracts as well, so that other assets may benefit from the same level of privacy.There are many exciting developments in the space of zero-knowledge proofs (STARKs, Zexe) but this exists today.GovernanceAlthing in ThingvellirVoteCurrently, delegate votes are counted based on their roll ownership at the beginning of the voting period. It makes a lot more sense to base it on their roll ownership at the end of the voting period. This means that delegates can set up an alternate address where they vote for the other side of an issue, and let their delegators move their delegation to that address if it is their preference. It puts the vote back in the hands of the token holders, but defaults to the delegator’s choice in case of apathy. That’s a very low hanging fruit.ConstitutionalismIt’s a good idea to start building up constitutionalism early on. By constitutionalism I mean protocol rules regarding the content of protocol upgrades. A refactoring of the code could ensure that every creation and destruction of token has to happen through a single OCaml module. This can be enforced via the type system. Further assume that this module programmatically limits the yearly issuance of tez. It would be straightforward to hold protocol amendments modifying this module to a higher standard than protocol amendments that don’t. For instance, modifying this module might require a stronger majority, or several confirmation votes over a longer period.The Tezos position paper mentions doing this by embedding a proof-checker in the protocol, this is the most general approach but it requires some heavy machinery. A lot of low hanging fruits can be plucked by merely expressing rules about which files can or cannot be modified. Here’s another example of what can be achieved through this technique: a module could consist of a series of filters that blocks have to go through before being considered by the protocol. An amendment which only adds filter would be the rough equivalent of a Bitcoin “soft-fork”. Differentiating between soft-“forks” and hard-“forks” can be done relatively easily from within the protocol.Mempool(no I’m not putting a stock picture of a pool there, enough already)An easy 2x gain in throughput would come from reworking the mempool. Specifically, the possibility of including transactions in a block should be fully determined without computing their effects. This is achieved if the mempool can cheaply ensure that the fee can be paid (invalid transactions are then included and treated as nops, as is already the case).One way to do this is to make it so that all fees are paid by the manager’s implicit account, even if the source is some other account. The mempool can then ensure that the managers have a sufficient balance to pay the fees they promise to pay, as of the previous block.This is a very minor restriction in terms of the blocks that can be created, but it has a large implication for the baker’s strategy. A baker can just grab the highest fee operations, shove them in a block, publish it, and only then take the time to analyze the effects of the operation. As part of this change, it would make sense to also merge “accounts” and “implicit accounts” which have no strong reason for remaining separate.Smart-contractsThe gas costs in Michelson need tuning in order to raise the gas limit in each block. Beyond that, and from a language perspective, it would be reasonable to add closures to the lambdas (with type annotations) and offer more polymorphism where possible. I don’t think I have a whole lot to contribute here given how strongly most Tezos developers gravitate towards expertise in programming language theory.Multiple entry points in contracts would be a nice standard to add. Offering cryptographic primitives in Michelson like elliptic curve point manipulation could yield some interesting use cases. Most of the work here is in the tooling layer which is explicitly out of scope for this post.ConclusionThere is no pretense of originality in the above (though I think the governance parts are novel). I believe Tezos’ strength will come from its ability to make steady, incremental, improvements based no only on its own community of developers and researcher, but also by tapping with discernment across the entire industry.A few directions to improve Tezos was originally published in tezos on Medium, where people are continuing the conversation by highlighting and responding to this story.


18. 10. 20

Towards Futarchy in Tezos

Futarchy, in a nutshell, is the governance technique of evaluating policies ex post while relying on a prediction market to determine the best policy ex ante.The Tezos position paper explicitly mentions futarchy as a possible development for the governance of Tezos. This blog post presents some concrete ideas for its implementation.This leads me to an important point: regulations should not, and do not curtail research and development of novel governance technologies. However, in order to ensure the successful deployment of those ideas one should be particularly mindful of the regulatory landscape so as not to run afoul of applicable laws. In order for these technologies to benefit as many people as possible, the best path forward is education, and engaging in constructive dialogue with regulators and lawmakers around the world.One more note, economist Robin Hanson coined Futarchy and deserves all the credit for introducing it as a governance mechanism and researching the machinery required to make it work. Whichever fraction of the total credit he feels is worth re-crediting is his to reassign.A quick primer on prediction marketsA prediction market is a financial tool for efficiently crowdsourcing predictions. The general idea is that the price of a financial asset reflects the discounted, risk neutral, expectation of a payoff. Stocks pay dividends, commodity futures lock in a price for purchasing commodities, etc. In these markets, traders can invest their time, money, and skills in order to detect mispricings (i.e. mispredictions) and trade accordingly. These trades move the market until the mispricings become smaller than the expected opportunity cost of detecting them.The term prediction market is typically applied broadly to markets whose payoff isn’t tied to a financial instrument. The payoff could be binary, based on the outcome of an event, for instance: “Will Republicans control the senate in 2018?” or “Will France win the world-cup in 2022?”. It could also be a more continuous payoff, for instance “+$1 for each degree over the seasonal average for NYC in 2019”.Financial instruments aren’t just traded in a zero sum speculative game. For instance, stocks are held for investment purposes, commodity futures can be bought by producers and consumers to hedge their exposure. Contracts whose payoff is based on the temperature do exist and are traded on the CME, albeit thinly. They can help electric utilities manage costs by predicting air conditioner use, or they can help landlords manage the variability of heating costs. Sport bets on the world cup also have an intrinsic utility: they make the games more exciting to watch!A pretty stock picture of some order book and candle graphInterestingly, financial economics teaches us that this demand (investment, hedging, insurance, entertainment) is required for the markets to exist among rational actors. This principle is called the no-trade theorem.To explain the no-trade theorem, imagine a game of Texas hold’em poker with no blinds. Of course, some players would play such a game (they would gamble), but an astute player would simply fold every hand until they hit the nuts, two aces. However, an equally astute player on the other end of the table would always fold in such a situation, knowing that the move indicates the other player has the nuts, unless of course they have the same hand. The no-trade theorem goes the same way. If there are no intrinsic reasons to trade on a market, the outcome is rational traders staring each other down, assuming that any bid indicates superior information.This result should not be a surprise. Making accurate predictions requires time, money, skills — all of which represent direct costs or opportunity costs. Someone has to be paying for all that research. In the stock market, the research is paid for by investors who cross the bid-ask spread thereby compensating market-makers for the money they lose to informed traders. In sports betting, it is paid by uninformed gamblers who cross the spread for the thrill of the game or out of delusion.Paradoxically, noise traders who buy and sell without sufficient supporting evidence make markets more accurate by subsidizing price discovery. However these traders can come and go, and it would seem imprudent to rely on their presence to harness the predictive power of these markets. The most natural way to subsidize price discovery in a market is to pay market makers to maintain tight, double sided quotes. A naive market maker constantly offering to buy or sell with a reasonable spread will naturally lose money to informed traders. Paying the market maker permits funneling a subsidy towards the most efficient forecasters.Futarchic governance on TezosFutarchy is a tool and there are several ways it could be applied in Tezos. In the following blog post I have attempted to move towards a more concrete proposal for futarchic governance in Tezos than the one outlined in the position paper.As Hanson puts it, the idea of futarchy is to “vote on values and bet on beliefs”. The idea is that values should reflect the subjective goals and preferences of the group sharing the resource being governed while determining the policies best suited to achieving those goals is best left to a more “objective” prediction market. Several markets can compare the expected merit of different policies and thus suggest the one to adopt.This leaves two questions open: where do futarchic decisions fit in the Tezos governance process, and what can those values be.Belt and suspenders governanceIn the current betanet governance, participants select amendment proposals through approval voting, hold a vote to decide on the proposal itself, and a bit later a confirmation vote. A natural approach would be to maintain the last two votes, but replace the approval vote with a futarchic based ranking. This has the benefit of leaving the vote as a solid check against possible failures of the futarchic process.In general, I believe that the conjunction of distinct governance processes generally compounds the benefits of each system and not the flaws. This “belt and suspenders” approach stems from the observation that governance procedures have more false positives than false negatives. A worthwhile proposal is likely to appear worthwhile under most lenses while a bad proposal may make it through only a few governance models. A demagogic proposal that would pass a vote may not pass the muster of a prediction market. A clearly adversarial proposal designed to slip through a blind spot of futarchy may not fool voters.This is not a free lunch: In the limit, if too many filters are applied, even good proposals may be rejected. The cost of introducing too many layers of governance too quickly is premature stasis. However, I believe this to be a very cheap lunch.ValuesWhat do participants in the governance process value and how can we measure it? Let’s start with a few observations:First, there isn’t necessarily a well defined answer to this question. There is no principled, meaningful way of aggregating individual preferences. However, preferences roughly point in the same direction. There is no rigorous, ironclad, definition of what exactly constitutes a birthday cake, but that shouldn’t stop people from baking them. Our inability to formalize the concept may reflect as much on the limits of our formalization abilities as on the concept itself.Second, an approximate proxy to the value may be sufficient. While optimization processes do tend to produce negative unexpected consequences when they are not optimizing exactly for the actual goal, the Tezos governance process is nowhere efficient enough to enjoy the luxury of having this problem.With those observations out of the way, several reasonable metrics come to mind. Some are intrinsic and can be computed on-chain, others are extrinsic and require the use of decentralized oracles.On a proof-of-work chain, a simple intrinsic metric could be hash-power as a reasonable proxy to the health of the network. However, it’s not a very good fit for Tezos which relies on a proof of stake.A simple, elegant, and intrinsic metric proposed by Ralph Merkle in 2016 is to rely on an ex post vote. Participants may not be good at deciding ex ante what is a good policy, but deciding out ex post if a decision was a good call is much easier. Instead of making a decision, the participants are asking the prediction markets to determine what policy they are likely to be satisfied with in the future. This isn’t perfect, but has the benefit of being clean and simple to implement.Extrinsic metricsExtrinsic metrics are also possible, but they require an oracle to provide “off-chain” information. This oracle could be centralized, for instance, if Tezos participants wanted to maximize the number of pandas in existence, they could entrust the WWF to provide this data to the blockchain. If they wanted to maximize adoption, they could task several auditors to estimate the number of individual participants. However, if the metric is more easily publicly verifiable, they could rely on a decentralized oracle to import that number into the system.The oracle at DelphiA general technique, for the oracle to propose a number, is to run a game where participants can place hidden bids onto a candidate number. After the bids are placed they are revealed and the tokens are redistributed according to a formula which rewards proximity to the median, for instance something proportional to 1/(1 +(choice-median)²). If the true value isn’t particularly controversial, a natural Schelling point in this game is to play one’s true estimate.A run of a decentralized oracle enabling panda-centric futarchyThere are known issues with this approach. In particular, a wealthy participant could make a strong, public commitment to back the wrong number and create an avalanche where his choice becomes the new Schelling point. A patch would be to offer voters the possibility to force a “do-over” if the settlement is rigged. It does improve things a bit, but it isn’t perfect.Alternatively a body could be elected to devise and compute a metric, with provisions to override their decision.Meet Leo, the panda.Measuring expected outcomesAssume a metric has been picked. For the sake of generality, we’ll pick a continuous metric as opposed to a binary one, as this represents the harder case, call it “x”.In the governance model we described earlier, several competing proposals are being analyzed by a prediction market. However, at most one of these proposals will be adopted in this cohort. How do we settle the prediction markets for the other ones? If we do not implement policy P how can we tell who was right and wrong about the effect of P on x?Conditional marketsThe solution is to make two predictions: one on the probability of proposition P being adopted, and one on the value of x conditional on P being adopted. You can think of the first market in terms of tokens.Consider a token called XTZ_P, which pays out 1 XTZ if P is adopted, and token XTZ_!P, which pays out 1 XTZ if P is not adopted. By a no arbitrage argument, 1 XTZ_P + 1 XTZ_!P = 1 XTZ. Likewise consider a token XTZ_P_x which pays out x XTZ if P is adopted and 0 XTZ otherwise, where x is the ultimate value of metric x. Another way to look at it is that XTZ_P_X unconditionally pays out exactly one x XTZ_P token.Form the ratio XTZ_P_x / XTZ_P, i.e. how many XTZ_P tokens does it take to purchase one XTZ_P_x contract. By a no arbitrage argument, this value should measure the expected value of x conditional on P being adopted. This estimate can be quite noisy if the proposition is unlikely to be adopted. Fortunately, we care about precise estimates for the propositions which are likely to be adopted. If a numerical instability led XTZ_P_x / XTZ_P to be overestimated, XTZ_P would actually rise, dissipating the numerical illusion.Market structureHow should the market for those instruments itself be structured? It’s not enough for these instruments to exist, a price must be formed, and it must be observable, on-chain.The most common market structure is the continuous double auction, where traders place bids and asks in an order book which matches crossing trades. This is the market structure adopted by most exchanges and it permits continuous trading. Another common structure is a batch auction, where orders are submitted blindly, and then crossed with each other at a price which maximizes the amount matched.Continuous markets are useful for traders who want the convenience of buying and selling at all times, but are they really necessary for futarchy, where we solely care about forming predictions? A simple approach would be to hold a single auction, where traders submit their orders into a smart-contract, forming a single price used for predictive purposes.While this has the benefit of simplicity, it carries a serious drawback: traders cannot observe and react to mispricings. In a continuous market, mispricings can attract the attention of traders with superior information who come in and correct the deviation. Furthermore, a naive single auction does not let traders express beliefs about the relationship between various events being bet on. Doing so requires the complexity of combinatorial market. A continuous market does not depend on combinatorial bets being available, as those bets can be placed in real time, one leg at a time.Microcosm of London — Auction room, Chritsie’sUltimately, finding the best structure is an empirical question. In the interest of concreteness, as a first shot, a reasonable structure would be to hold five, one hour long, batch auctions over a period of two weeks. This is assuming there are at most 10 proposals being considered simultaneously. This is unlikely to be optimal, but it’s also unlikely that further research would yield radically better outcomes.Automated market makingAs mentioned in the introduction, a key to extract good forecasts from prediction markets is to subsidize market making. In Tezos, this can be done through inflation by issuing new tokens to automated market making contracts.The goal of these market making contracts is to provide liquidity and lose their subsidy to informed traders who will push the price towards a good forecast. What strategy should our automated market making contract follow? Let’s forget about outsmarting other traders, a reasonable goal is inventory management. So long as the market maker does not run out of money, it will be able to provide some quotes, so let’s try to keep our pockets full.Assume the market maker initially sits on n XTZ, these can be converted into n XTX_P tokens and n XTZ_!P tokens. Denote by a the quantity of XTP_P tokens in the inventory and by b the quantity of XTZ_!P tokens in the inventory. Initially, (a=n, b=n).In order to maintain its inventory, our market maker will try to maximize ½(Log(a) + Log(b)). This is a simple way of expressing a preference for not running out of either side of the bet, but it’s also equivalent to saying the market maker believes the event has a 50% chance of happening, and has a logarithmic utility.How much should we charge to sell 1 XTP_P token? Suppose we receive q XTP_!P tokens, we will charge a price that leaves us indifferent. Log(a - 1) + Log(b + q) = Log(a) + Log(b) => q = b/(a-1). Conversely, we should be willing to pay b/(1+a) XTZ_!P tokens to buy 1 XTZ_P. The probability estimate is then given as b / (2 a ). That is, if the market maker ends up owning a lot of the XTZ_!P contract, it is likely that P will be adopted!Following this algorithm, the market maker will let its quotes be pushed around by the flow. While the market maker may be wrong about its utility function, it is consistent and thus cannot be gamed… it will lose money to informed traders, but uninformed traders cannot systematically extract money from it.It is possible to devise better algorithms that take into account the time remaining. The techniques are based on optimal stochastic control. However, the algorithm above is dead simple and a good first approximation. For more color on the topic, see Hanson, R. (2002). Logarithmic Market Scoring Rules for Modular Combinatorial Information Aggregation.Next stepsWe’ve covered the main aspects of a futarchy proposal in Tezos. This proposal needs to be further refined by filling a few gaps. Which specific measure should be maximized? When should the market resolve? Resolving markets before the adoption of the proposal prevents gaming of the mechanism through proposals that change the market resolution code, but resolving them later gives more time for the policy to make an impact on the value being measured. How large should be the market subsidy? Should the market for all proposals be subsidized? Should a round of approval voting be used to decide which market should be subsidized? Perhaps a fixed number of proposal slots should be periodically auctioned on the network. Fine-tuning all these details is a painstaking task as this is new ground and there are few antecedents to go by.Thank you to all the people who helped me refine this piece. I’d love to list your name if you do not mind the (minor) loss of privacy.Towards Futarchy in Tezos was originally published in tezos on Medium, where people are continuing the conversation by highlighting and responding to this story.


18. 08. 19

Liquid Proof-of-Stake

tl;dr: Tezos allows token holders to transfer (“delegate”) validation rights to other token holders without transferring ownership. This has led many observers to confuse Tezos’ consensus mechanism with the delegated proof-of-stake (“dPOS”) model specific to EOS or Lisk. In dPOS, election of a fixed set of Block Producers (i.e. delegates) is required for network consensus. In Tezos, delegation is optional. I propose we instead refer to Tezos’ consensus mechanism as “Liquid Proof-of-Stake” or “LPOS”. LPOS aims to maintain a dynamic validator set, facilitating token holder coordination and accountable governance.All in all, the barrier to entry to validation in Tezos is significantly lower than in standard dPOS (or proof-of-work for that matter), with the current protocol requiring a baker to have 10,000 ꜩ, a reliable internet connection, good opsec, modest computing power and technical know-how.Baking in TezosWhereas in Bitcoin a miner’s right to publish a block is determined by solving a cryptographic puzzle, a mechanism known as proof-of-work, Tezos allocates block publishing rights based on stake, a mechanism known as proof-of-stake. Each block is produced (“baked”) by a random stakeholder and notarized (“endorsed”) by 32 other random stakeholders.Like Bitcoin, Tezos uses inflationary block rewards and transaction fees to incentivize validators (or “bakers” in Tezos parlance) to participate in consensus. To incentivize honest behavior around the time of block creation, Tezos requires a baker to put up a safety deposit for several weeks. If a baker explicitly tries to double bake or double sign blocks, it forfeits this safety deposit.Token holders not interested in baking themselves may delegate baking rights without transferring token ownership. As described earlier this year in “It’s a baker’s life for me”:Since not everyone holding tokens is interested in being a baker, tokens can be “delegated” to another party. The delegate does not own or control the tokens in any way. In particular, it cannot spend them. However, if and when one of these tokens is randomly selected to bake a block, that right will belong to the delegate.But unlike in Bitcoin, in which miners capture all inflationary block rewards, Tezos delegates compete by sharing their inflationary baking rewards with delegators. All Tezos token holders, regardless of stake, can avoid being diluted by the targeted ~5.5% annual inflation, fostering greater coordination.Delegated Proof-of-Stake (dPOS)Because Tezos allows delegation, its consensus mechanism has often been described as delegated proof-of-stake, or “dPOS”. This has caused many observers to confuse proof-of-stake in Tezos with a very specific consensus mechanism used by EOS, BitShares, TRON, ARK, and Lisk*.But in the standard dPOS model, delegation to a fixed number of block producers or “witnesses” (i.e. 21 Block Producers in EOS) is a requirement for network consensus rather than an option as in Tezos.The use of dPOS for consensus typically stems from the belief that scalability is the main bottleneck to mainstream adoption of blockchain-based dapps. Or in the words of EOS documentation:The EOS.IO software introduces a new blockchain architecture designed to enable vertical and horizontal scaling of decentralized applications. […] The resulting technology is a blockchain architecture that scales to millions of transactions per second, eliminates user fees, and allows for quick and easy deployment of decentralized applications.EOS takes dPOS further by adding Byzantine Fault Tolerance, by which dPOS-inventor Dan Larimer claims the network can achieve 99.999% finality in less than a second.In other words, dPOS might finally allow us to leave behind an era in which a pack of digital kittens can congest the proverbial world computer with non-fungible fur balls.To keep this small set of block producers honest and accountable, dPOS protocols continuously vote to select a set of delegates to publish and validate blocks. In EOS, token holders elect 21 Block Producers and 100 standby Block Producers, with results calculated every two minutes. In Lisk, token holders constantly elect 101 delegates. Voting power in dPOS protocols is typically proportionate to the token holder’s stake.Larimer argues dPOS also offers greater decentralization compared to Bitcoin and Ethereum, in which mining activity has become quite centralized. Unlike Tezos, which assigns baking rights proportional to stake, dPOS splits block production rights evenly within the set of active block producers. The risk of Sibyls and cartels aside, the 21st most voted validator technically has as much say as the most popular block producer.And with a fixed validator set, dPOS also requires less inflation to incentivize block production. Of its 5% annual inflation rate, EOS allocates only 1% to Block Producers (a share goes to standby block producers), with the other 4% allocated to an on-chain treasury intended to fund public goods for the network.Fixing the validator set to 21 or 101 nodes harnesses intense competition between aspiring block producers, but also creates a barrier to entry in consensus participation. After all, EOS’ plans to scale to millions of transactions per second, likely requiring any block producer to meet significant infrastructure requirements. The entire EOS Block Producer list is likely to become professionalized to the scale of modern bitcoin mining (or even be Bitcoin miners themselves), a far cry from the dorm room GPU mining of the early Bitcoin days.Towards Liquid Proof-of-StakeBut unlike in dPOS, delegation is not the salient aspect of proof-of-stake in Tezos. The project holds decentralization, coordination, and security as core priorities over scaling immediately and throughput (currently ~40 tps) is to be dialed up carefully.In fact, Tezos’ flavor of proof-of-stake is more akin to “proof-of-stake with delegation” than it is to dPOS. To resolve the confusion and better describe proof-of-stake in Tezos, I propose we begin to call the Tezos consensus mechanism “Liquid Proof-of-Stake”, or “LPOS”.In the weeks since betanet launch, Tezos has seen rapid growth in the number of delegates and 411 bakers are set to bake in cycle 15. But as the diagram below demonstrates, we have already seen some churn in the delegation market as delegates compete based on fees, payout frequency, reputation, and other metrics.In Tezos, delegate misbehavior (e.g. not paying out rewards) is likely to be detected quickly and the community is quick to castigate a delegate for charging high fees. Token holders face little friction when switching delegates and thus can credibly threaten to delegate elsewhere, incentivizing coordination instead.Above is the distribution of bakers from cycle 1 to 15 of Tezos betanet. Baking has decentralized significantly since launch and will decentralize further as better infrastructure becomes widely available.The protocol will eventually require fewer tez to bake (e.g. 2,000 ꜩ instead of the current 10,000 tz) than the tez in the median wallet (2,332 ꜩ) created in the 2017 fundraiser. This offers a viable path to baking for many thousands of users.And exciting infrastructure efforts, such as BakeChain, “set and forget” baking hardware (“easy-bake-oven”, anyone?), and perhaps someday mobile-controlled bakers, are all likely to reduce frictions to baking further still.Implications for on-chain governanceAll of this becomes especially important in the context of on-chain governance, because consensus participants are the decision-makers regarding protocol upgrades in Tezos. A token holder who delegates baking rights also delegates voting rights.On this topic, there’s no shortage of celebrated blog posts forewarning us that on-chain governance is destined for capture by concentrated interests. And there is real evidence to this effect in Lisk. But observers too often extrapolate the experiences of dPOS protocols with fixed size validator sets directly onto Tezos. Rarely do observers note that Tezos features a different model based on different priorities.None of this is to say that powerful voting coalitions can’t arise, or that large entities, like exchanges, won’t become important stakeholders in Tezos. But what matters most is whether token holders and users can coordinate to rearrange power and hold concentrated interests accountable. Liquid Proof-of-Stake should facilitate this by ensuring the barrier to entry is low enough to maintain a dynamic validator set.But like infosec, accountable governance is a challenge which can never be “solved” absolutely.Alternatively, baking and voting rights could be unbundled entirely, further loosening the connection between consensus and on-chain governance. This may require changing strong defaults, as users might delegate their baking rights to one entity and their voting rights to another. Not to mention all the other potential tradeoffs. But it is an intriguing area of research and, of course, in need of a subsequent Medium post.Notes[*] There are nuanced differences between different dPOS protocols, but they usually follow the fixed validator set model which BitShares first introduced to the worldLiquid Proof-of-Stake was originally published in tezos on Medium, where people are continuing the conversation by highlighting and responding to this story.


18. 07. 30

The Myth of the Irrational ...

Blockchain governance doesn’t fit squarely into any existing model.Tezos is a blockchain with a first-in-kind implementation of a native governance mechanism. All proposed changes to the protocol are decided upon by the community, then pushed automatically to the network. By providing a way to decide upon and enforce upgrades in a decentralized fashion, our team believes we can launch an innovative platform that does not fall privy to the whims of a centralized core development team.When people first hear about our platform, they typically relate it to a governance structure they’re familiar with. We think that the nature of blockchain-based systems offers a unique model.Skin in the gameTezos has no concept of a registered identity, so all decisions on protocol changes will be weighed in proportion to the quantity of tokens owned by a participant. Some assume that our system ought to have “one person, one vote.” However, entities are hard to group or identify meaningfully when ownership is controlled by a cryptographic key and, more importantly, we prefer to have those with the greatest skin in the game impacting long term decisions.We see proportional voting based on ownership of tokens as a desirable trait of our governance system. In fact, the title of this post is a play on the title of Bryan Caplan’s book, The Myth of the Rational Voter, wherein Caplan observes that voters in a democracy rarely have incentives to consider their beliefs thoughtfully. Though it doesn’t inspire a civic spirit, it’s fair to say that devoting little time to considering electoral issues is rational insofar as most policy decisions don’t make any direct impact on the welfare of most voters. By contrast, when it is explicitly costly to be wrong, actors have a tendency to give more thought to their decisions and may even act in a way that goes against their biases.And so, when people object to relying on the opinions of token holders to govern our blockchain by citing poor outcomes in democracies such as massive property redistribution, it doesn’t really resonate with our model. We think of Tezos governance as being more similar to the dynamics of corporate governance than the dynamics of a democracy. That is, all the relevant parties have a theoretical interest in critically thinking in order to preserve the value of the network and people with more skin in the game have a greater stake in those choices.Stockholders versus token holdersSome interlocutors will latch on to the similarities to corporate governance structures and Tezos immediately. Part of what invites this comparison is our use of delegates to vote, which can replicate the logic of proxies in a corporate setting. (This has also been referred to as “liquid democracy.”) At this point, some interesting scenarios are presented as theoretical objections. Corporations are not perfectly governed and, what’s more, it’s not necessarily costly for executives or activist shareholders to make bad decisions once they have positions of power. This is a flipside of the tension with democratic processes: won’t large token holders have too much power?While we can learn a lot from failures of corporate governance structures, we think there’s a key distinction to be made when considering blockchains as a particular use case. The only asset of a blockchain-based network is the faith of the people who use it. Cryptographic tokens, much like fiat money, are lifted and destroyed by the belief that other people will find them valuable and want to hold them.Recently, Vitalik Buterin speculated that, in the Tezos network, one could feasibly use bribery to create a coalition to vote for explicitly favorable laws towards one group at the expense of another. An evil corporate raider raising her stake in an oil rig company from 50% to 100% by bribing the board owns twice as many oil rigs as she did before. However, in the case of blockchain assets, it’s very clear to us that this sort of tampering would only yield, in the words of Voltaire*, rule over cemeteries from once-fertile plains. (This also goes without mentioning that the same “attack” is no less feasible within the highly centralized decision-making processes of existing public blockchains, particularly those with a propensity to hard-fork.) Once a community has reason to believe that the deck is set against them by a few select actors, the network loses its value in an irrevocable way.Additionally, if a group of actors did try and succeed in pushing through amendments that disproportionately hurt a group, social consensus would simply take over. If a group of Bitcoin miners somehow managed to abscond with some Bitcoins through a deep reorganization of the chain, there’s no doubt that the other people holding a stake in its $17 billion market capitalization would find a way to exclude or ignore the responsible parties.To be clear… In our first iteration, we use a straight vote (with an option to delegate your vote) to select, then accept or reject, upgrades to the network. We don’t believe that our governance model is anywhere near perfect — which is why we created a mechanism to change it within the protocol itself. There are many opportunities to improve upon this model. Through the use of formal proofs, for example, we can incorporate a sort of economic constitutionalism by requiring mathematical evidence that all code submissions satisfy certain properties such as capping coin issuance. By running a prediction market for proposals, we can introduce a form of futarchy. There’s even room to express some form of representative democracy through elected councils.There are many theoretical objections to what we have proposed, not least of which is the fallibility of our wholesale judgement. However, we have reason to believe that the flavors of our issues will be different than what we see in a corporation or Congress. The nature of blockchains represents an interesting opportunity to create a new decentralized paradigm.Thomas Jefferson experimented with new governance mechanisms and cryptography! … but not at the same time.* “Their principal dementia is their frenzy for shedding their brothers’ blood, and for devastating fertile plains so that they may rule over cemeteries.” The Princess of Babylon, VoltaireThe Myth of the Irrational Token Holder was originally published in tezos on Medium, where people are continuing the conversation by highlighting and responding to this story.


17. 02. 20

Explaining My Project to My...

My mom is a smart lady but she’s not an avowed cypherpunk or CS professor. Here’s how I explain Tezos to her.Over the last five years, cryptocurrencies such as Bitcoin have come into some popularity. To date, the cryptocurrency market is ~$13bn across the leading efforts in the space. These projects can serve many uses, like offering a native digital asset of the Internet or providing alternative stores of value for the unbanked/those subject to poor monetary policy.These applications are powered by a blockchain. In a cryptocurrency, a blockchain registers and validates transactions in a public ledger, removing the use of a third party to maintain a registry of who-owns-what by running a global protocol to evaluate and store transaction information. Blockchains allow many different parties to come to consensus on the state of asset allocation.Ironically, this really sophisticated piece of accounting software currently offers no way to come to consensus about the rules that govern it. That is, when a new feature needs to be added or amended, it’s impossible for the users to coordinate updates on the blockchain because there’s no “governance layer” to act as a forum to move the blockchain along. As a result, innovation in the space has been relegated “off-chain”, where either feuding parties lack a means to convince the network of the merits of their upgrades — resulting in stasis — or enclaves of influential developers govern the codebase in an oligopolistic fashion.In 2014, my husband and I identified a lack of governance mechanisms in cryptocurrencies as a destabilizing vulnerability. Our solution to this is to fold in a mechanism for enforcing protocol changes/upgrades onto the ledger itself. It’s sort of like a digital game of nomic, a game in which changing the rules is a move.With our technology, we can amend technical aspects of the network but also instantiate rich governance rules through the use of formal proofs. Writing programs is error prone but, with some effort, programs can be given a mathematical treatment to prove that they do what we want them to do. If we want to cap the issuance of tokens at a certain amount, we can make sure that all proposals to the network satisfy this cap mathematically before allowing users to opine on the code. This replicates the logic of constitutional amendments in the US.Bitcoin and other cryptocurrencies are a powerful tool for programming value. However, without a way to enhance themselves in an open and transparent manner, they will be crippled by the types of centralized politics that currently stagnates innovation in the Internet. Decentralizing governance is a potential solution to this problem, one that we’re trying to help realize with our team.Explaining My Project to My Mom was originally published in tezos on Medium, where people are continuing the conversation by highlighting and responding to this story.


16. 10. 30

Transaction History
Transaction History Address
HitBTC Short cut
Huobi Global Short cut
Kraken Short cut
Bitfinex Short cut
Gate.io Short cut
ZB.COM Short cut
BitMax Short cut
WazirX Short cut
LiveCoin Short cut
RightBTC Short cut
CoinAll Short cut
BitMEX Short cut
Coinone Short cut
Security verification

There is security verification of the project
Why security verification is necessary?

Read more


* Written questions can not be edited.

* The questions will be answered directly by the token team.

Platform BTC
Hard cap -
Audit -
Stage -
Location -