arXiv:1909.08458v1 [cs.DC] 18 Sep 2019 eea set oprdt oeetbihdblockchains. established more original an to offers compared aspects several oe n asstercie esgst h etlyrthat layer a next as the network to messages this received sees the passes and nodes A eevdb oehst evldtdbfr h oeagrees node the before validated be to has node a by triggers received which call code. function smart-contracts a as the smart-contract. seen of a be execution to can the addressed they be blockchain case can the this and on just In data than residing carry (assets more can tokens be they blockchain of can perform transfers ledger and mere the their in storage manage Transactions data that operations. and programs small tokens are associated contracts Smart ledger. form. the in included be wit can blocks which transactions decides which it consensus: the implements which mn t w osnu loih admr)truha improve through to more) methods formal (and on safety. focuses algorithm capacity and consensus mechanism the voting own has original It its an platform. amend offers contract smart It decentralized [3]. like Ethereum blockchains of-Stake’ established or more [2] to Bitcoin compared aspects eral nodes. of thousands among ledger) (usu a consensus bringing over at aim that programs decentralized ehns n oue nfra ehd oipoesafety. voting improve a to th through methods has formal protocol It on economic platform. focuses own contract and its mechanism smart amend decentralized to a capacity as used be lccan;satcnrcs omlverification. formal contracts; smart blockchains; n assnwifraint the to information identifier new block new passes pushes and neighbors, its from chunks block hsi rf ae ftettra umte oHC 2019 HPCS to 2019). submitted July tutorial 19 the to of 15 http://hpcs2019.cisedu.info/4-program/tutorials-hpc paper from Ireland draft (Dublin, a is This Abstract oesr h ossec ftelde tt,ec block each state, ledger the of consistency the ensure To plat- contract smart a embeds also protocol economic The eo mlmnaini einda ut-ae software multi-layer a as designed is implementation Tezos sev- improves that blockchain innovative an is [1] Tezos and distributed massively lay blockchains of heart the At Keywords peer-to-peer Tzsi ninvtv lccanta mrvson improves that blockchain innovative an is —Tezos 4 osnu loih n a eue sa as used be can and algorithm consensus [4] — .I I. TOUTO TO NTRODUCTION ae nue h onciiywt ayother many with connectivity the ensures layer itiue ytm;dcnrlzdsystems; decentralized systems; distributed nrdcint h eo Blockchain Tezos the to Introduction proof-of-stake itiue database distributed itrAllombert Victor osnu loih n can and algorithm consensus B LOCKCHAINS cnmcprotocol economic mi:fi[email protected] Email: PS21 NIE UOILPAPER TUTORIAL INVITED 2019 HPCS hslyrpulls layer This . ∗ s2019 oai as ai,France Paris, Labs, Nomadic ∗ aha Bourgoin Mathias , ’Proof- layer ally to It s, ), h e . hog utpeeape.Scin3soshwt s the use to how and shows blockchai client a Tezos 3 through the Section blockchain with examples. interacting multiple on through ne The focus Tezos. We of will Tezos. specifics some sections of with detail rest interact will the 2 in and Section blockchains Section. to use introduction to short a how with begin and is blockchain a a network. for the important down stora very slow and to is time not both it in order thus limited in be neighbor, to execution its contract to smart it transfer to nadcnrlzdntok hyaebituo eea key several upon built are tools: They and network. concepts decentralized a in blocks building Blockchains A. an language programming technica contract some platform. smart providing Tezos while the to contract of how details small that examples a platform through run present and decentralized 4, We build a contracts. Section as smart In Tezos run use language. can to programming how any present from we used be can hsbokhisaeotncalled often are blockchains Thus oet etitn h olo lc rdcr a lolea also can be producers to block network of the and pool of of resource the use majority this to Restricting the the choose honest. is push to to that it is solution incentives difficulty tying a create A by [6] resource. producers attacks scarce block a of Sybil pool to the resilient restrict be To lenges. l lccan olwasmlrgnrcalgorithm: generic similar a follow blockchains all dniyadbo muaiiyaecytgahclyensu cryptographically are us immutability where book transactions and recording identity book, electronic an as seen )Ndsepesteracpac fabokb including by block a nodes. several of or acceptance one their by express which broadcast Nodes is nodes 3) block all next The to 2) broadcasted are transactions New 1) hsttra isa iigabodpeetto fwhat of presentation broad a giving at aims tutorial This lccan a ese sa mual aaaeoperating database immutable an as seen be can Blockchains lccan aesm omndsrbtdsseschal- systems distributed common some face Blockchains nodrt aiaeadapn rnatost h ledger, the to transactions append and validate to order In • • • hyueape ope PP ospntokfrlow- for network gossip nodes. (P2P) the peer between to the communications peer level in tutorial) a this use of They rest the in participants network nodes decentralized all call among will consensus we (that for gen- [5] “Byzantine the problem” to erals solution immutability probabilistic database a offer the authenti- They as users well ensure as to cation heavily cryptography use They t rporpi ahi h etbokte create. they block next the in hash cryptographic its blocks. in them aggregate ∗ n uinTesson Julien and ∗ via crypto-ledgers ihsto P al that calls RPC of set rich a ste a be can they as red. this ers ge xt d d n l to liveness issues that have to be taken into account to make pushed the concept further. The main idea is to see blockchains sure that the chain does not stop whenever a block producer as vending machines where users can pay for a service. In is offline. Blockchains also have to consider malicious block blockchain platforms, these services are small programs living producers and performance issues such as network delays. on the chain. Users of the blockchain can store code in Each blockchain provides its own set of solutions to overcome blocks and other users can execute this code. These programs these challenges but most of them rely on the foundations set are called Smart Contracts. They can, of course, perform by Bitcoin. Blockchains also face the risk of forks: to update blockchain operations, such as token transfers, but they can their economic protocol, blockchains have to go through social also be used for access control or to interact with others. consensus and risk frictions in their user community that may Some smart contracts, being fed with off-chain information, lead to the birth of hard forks splitting the community in two serve as Oracles selling trusted information. Smart contracts parts agreeing on two different chains. Such hard fork occurred can be used in many applications such as financial contracts, after the Ethereum DAO hack1 leading to the birth of two developing new currencies on top of the basic crypto-currency blockchains: Ethereum Classic and Ethereum. of the blockchain, voting systems, games or crowdfunding.
B. Bitcoin: the electronic cash II. TEZOS SPECIFICS Bitcoin was introduced in 2008. The main objective behind Tezos is an innovative blockchain which was presented in Bitcoin was to propose a decentralized electronic cash system. 2014. Contrarily to most new blockchains at that time, it is Bitcoin is the name of the blockchain as well as the name of not based on PoW. In the following section, we present some the cryptocurrency it uses. Blockchains use tokens to represent distinctive features of Tezos briefly such as its self-amending assets stored in the chain. Some of these tokens, as in Bitcoin, mechanism, its usage of a ’Proof-of-Stake’ based consensus can represent a currency. Bitcoin is also a decentralized system algorithm and its strong emphasis on formal verification. (the actual blockchain) allowing users to store and transfer A. Self amending blockchain their tokens. This system is the combination of a P2P network Tezos is a self-amending crypto-ledger. The protocol that associated with a consensus protocol to maintain consistency validates blocks and implements the consensus algorithm can between nodes. This consensus algorithm introduced the no- amend itself. Concretely a new protocol is downloaded from tion of ’Proof-of-Work’ (PoW). With PoW, the scarce resource the network, compiled and how-swapped to replace the current used to restrict the pool of block producers (that Bitcoin one. calls ’miners’) is computing power. High computing power The amendment procedure can be triggered in several ways, mostly demands very efficient computing hardware associated depending on the protocol. In the current Tezos economic with high energy consumption. The main idea is to request protocol, an amendment can only be triggered as the result that miners compete in the solving of a puzzle to earn the of an on-chain voting procedure. right to produce (mine) the next block. The puzzle is built It helps to avoid forks of the chain and reduces friction to be hard to solve but easy to check. With PoW, Sybil and splitting in the community. A protocol amendment may attacks are difficult and expensive. Associated with incentives consist of very important upgrades such as a switch to a to motivate miners to compete, liveness is easy to achieve. completely different consensus protocol. It can also consist In case of soft forks (temporary split) of the chain, which in smaller modifications such as extending the smart contract can be caused by bugs, network latency or malicious mining, language, modifying the rewarding system to enforce network and to maintain consistency of the chain among all the nodes, participation or adding new kinds of transactions (for instance Bitcoin’s consensus algorithm specifies to always keep the adding anonymous ones). In order to amend itself, Tezos uses longest chain between two forks. A chain is considered longer an on-chain voting system where users of the blockchain if its total difficulty (summing the difficulty of the puzzles participate to propose, select, adopt or reject new amendments. solved to mine each block of the chain) is higher. The difficulty The voting process is currently divided in 4 periods of ~3 is adapted every two weeks to maintain an average of 10- weeks (time is measured in blocks, Tezos aiming at a -minute minute intervals between two consecutive blocks depending 1 intervals between two consecutive blocks): on the global computing power of the miners. PoW is the solution currently used by most blockchains. 1) Participants submit new protocol proposals (i.e. hashes of the protocol proposals source files) C. Smart Contracts: decentralized platforms 2) A first vote selects a proposal among the submitted While Bitcoin focused on electronic cash, it also come with proposal the concept of decentralized computations: Bitcoin’s script 3) A side test chain spawns with the elected protocol allows many interesting forms of in-transaction computation, 4) A final vote occurs that decides whether to up- and others quickly proposed to use blockchains to build de- grade(needing a supermajority of 80% of positive votes) centralized computing platforms. This was popularized by the Tezos is built specifically in order to be self-amendable. current second-biggest blockchain, Ethereum, in 2014, which Tezos nodes are split into two parts: the protocol, which is the self amendable part, and which is isolated from the shell that 1https://www.bloomberg.com/features/2017-the-ether-thief/ is responsible for the low-level network communications. The shell can be written in any programming language. at least a roll of tokens (corresponding to 10, 000 tokens2). There can be multiple implementations with different proper- The number of baking slots is proportional to the number of ties. It corresponds to the first two layers of Tezos architecture. rolls that a baker holds. However, participants that do not hold The protocol has to run exactly the same way on all nodes. It enough tokens or who do not wish to bake blocks can delegate is responsible for validating blocks and operations. Operations, their tokens to another baker, much like in Liquid Democracy that are aggregated into blocks, are what is stored in the ledger one can delegate its right to vote. They keep the ownership and are of two kinds: of their tokens but increase the stake of their delegate in the random assignment of baking slots. Delegation makes the PoS • ledger operations: transactions and origination (creation) system more fair and participative and helps balance a possible of contracts concentration of tokens in few hands. • Proof-of-Stake operations such as endorsements or dele- In order to help the chain reach finality (the guarantee gation that are described in Section 2.2. that a block will not be revoked and that past transactions The protocol can also trigger a protocol upgrade. In order to can never change) faster, Tezos PoS mechanism introduces allow all kinds of protocols to be compatible with the shell, endorsements of baked blocks. For each baked block, 32 Tezos reduces the protocol interface as much as possible. endorsements (signatures) slots are created, allowing chosen In Tezos, the generic operations of regular blockchains are bakers to approve a block by signing it. Using endorsements, implemented as a purely functional module. Thus, well known the highest block resulting score is considered the head of the blockchains such as Bitcoin or Ethereum can all be represented chain where the score is: within Tezos by implementing the correct interface to the shell. The interface of the protocol is primarily composed of two functions: apply and score. score(Bn+1) = 1+ score(Bn)+ nb_endorsements In order to provide incentives to bakers for participating in × → apply : S B S the network, the protocol rewards baking and endorsing. A → N score : S baker earns 16 tokens for each block it bakes and 2 tokens for each endorsement it produces. where S, the state of the blockchain (the ledger), is an Two main malicious behaviors are also handled by the immutable key-value store and B is a block. apply takes protocol: double baking and double endorsement. A baker the current state and a block to produce a new state. score perpetrates double baking when it injects two different blocks computes the score of a state to choose the preferred one at the same level. Double endorsements happens when a between multiple states (implemented as the longest chain baker signs two different blocks for the same level. The in Bitcoin). A few other functions are exposed for efficiency system punishes malicious behaviors as follows: when a baker ∼ purposes, to document errors and provide protocol-dependent produces a block, a deposit bond of 256 tokens is frozen for 2 RPCs. weeks (64 tokens for an endorsement). During this period, if Tezos protocols are written in the OCaml programming the baker/endorser is caught cheating, the deposit and pending language [7]. OCaml is a powerful functional programming rewards (summing the rewards earned baking and endorsing in − language offering speed, an unambiguous syntax and semantic, the last 5 cycles a cycle equals 4096 blocks) of the cheater and a rich ecosystem that makes Tezos a good candidate for are forfeited. formal proofs of correctness. To make it more resilient and Tezos LPoS consensus algorithm, via its internal mechanism less error-prone, the protocol has only restricted access to and its associated incentives, solves the challenges presented in the standard library: for instance it uses no I/O functions, no Section 1 without requiring significant computational power. threads, no unsafe language traits. It also has access to specific It also focuses on the users of the platform (instead of external libraries such as formally verified cryptographic libraries or actors as it is possible with PoW): not only stake-holders can database abstractions. participate but all users can, from large ones with many rolls to smaller ones that delegate their stake.
B. ’Proof-of-stake’ based consensus algorithm C. Strong emphasis on formal verification The current Tezos protocol is based on a ’Liquid Proof-of- Tezos uses as much as possible state-of-the-art program- Stake’ (LPoS) consensus algorithm. ming languages capacities to statically ensure the correctness PoS is very different from PoW. It considers the stake (the of the implementation and limit the possible runtime errors or number of tokens) that users hold as the primary resource attacks. used to build the pool of block producers (called bakers in the The code base is mainly written in the OCaml programming Tezos ecosystem). In the current Tezos consensus protocol, to language, whose robust static type system and memory man- push a block at a certain level, bakers are randomly selected 210, 000 tokens while writing these lines. An amendment of the protocol, using a lazy infinite priority list of baking slots. In order currently in the testing phase of the voting process described in the previous to participate in this random selection, a baker must hold subsection, reduces the size of a roll to 8, 000 tokens agement system rule out many common runtime errors like A. Seting up a Tezos node (demo) null pointer exceptions or buffer overflows. The node (tezos-node) can be considered as the access Regarding cryptographic primitives implementation, whose point to the Tezos blockchain and stores all the data necessary importance in terms of security is paramount for the to run the blockchain. In practice, the node’s data is stored (by blockchain, Tezos relies on the HACL* library [8] which is im- default) into the § /.tezos-node§ directory. plemented in Low* [9] and extracted to C. The cryptographic To be connected to the network, a node must have a proper primitive implementation is formally proven to be memory network identity to be globally identified. safe, functionally correct and resistant to side-channel attacks To generate an identity, the following command should be at least at the level of C (secret independence of branching run: and memory access). tezos-node identity generate Michelson, the Tezos smart contract language, has been explicitly designed to ease the readability and verifiability of The generated identity will be stored as a pair of cryp- contracts while being low level enough to comply with the tographic keys that are used by the node to send encrypted performance predictability requirement of on-chain execution. messages, but it is also used as an antispam measure (to The language is statically typed, its formal semantics has been prevent Sybil attacks) based on a lightweight PoW. written in the Coq proof assistant [10] and formal proofs of When the identity is generated, we can run a node using: functional correctness of smart contract using this semantics tezos-node run --rpc-addr 127.0.0.1 have been done. The -rpc-addr 127.0.0.1 argument is used to allow III.INTERACTINGWITHTHE TEZOS BLOCKCHAIN communications with clients on the local host only. The node The architecture of Tezos is centered around two main is now able to connect to the Tezos network and will start its components. bootstrap phase. It consists in downloading all the blocks from First, the node (the corresponding executable file being the chain using the distributed network. This procedure can be called tezos-node) is responsible for connecting to peers very long as the chain data is growing invariably every day. To speedup the process (from days to minutes), it is possible through the gossip network and updating the ledger’s state 3 (context). As all the blocks and operations are exchanged to start a node from a snapshot of the chain by running: between nodes on the gossip network, the node is able to tezos-node snapshot import last.full filter and propagate data from/to its connected peers. Using This command is able to read all the necessary data stored the blocks received on the gossip network, the node keeps an in the last.full file, validate it and import it in the node up-to-date context. The node can be run with several daemons storage. The imported data consist in a partial ledger state (that such as tezos-baker- and tezos-endorser- which * * can be reconstructed on request) and all the blocks of the chain take part of the consensus algorithm by, respectively, baking since the genesis. It is also possible to set up a lightweight and endorsing blocks. node targeting low resource architectures by running a partial Second, the client (tezos-client) is the main tool to chain using a rolling snapshot. When the import is done, one interact with a Tezos blockchain node. can run the node, and wait a few minutes to download the There are currently 3 public Tezos networks: new blocks spawned since the snapshot file was exported. • mainnet which is the current incarnation of the Tezos blockchain. It runs with real tez (Tezos tokens) that have B. Using basic client commands (demo) been baked or allocated to the donors of July 2017 The client (§tezos-client-full§) is a user-friendly interface fundraiser. It has been live and open since June 30th 2018 that can be used to interact with a node. As it is based • alphanet which is based on the §mainnet§ code base but on JSON RPCS, it can be requested by various third-party uses free tokens. It is the reference network for developers applications. For the sake of brevity, we will use §tezos-client§ wanting to test their software. instead of §tezos-client-full§ in the rest of the document. • zeronet which is the testing network, with free tokens The client can be used to check if the current head of and frequent resets. the local node is up-to-date using §tezos-client bootstrapped§. In this tutorial, we will use the §alphanet§ Tezos network. This command will hang and return only when the node is In the following sections, we assume that the reader have synchronised. access to the Tezos binaries. A pre-configured Tezos en- The client is also able to handle a simple wallet, stored vironment can be found in the provided virtual machine. (by default) in the § /.tezos-client§ directory. It mainly Otherwise, it is possible to install a Tezos environment contains 3 files : public_keys, secret_keys and from source (using the ocaml package manager (opam) and public_key_hashes (Tezos addresses : tz1). To generate compiling from source) or with docker (using scripts and a new pair of keys to be used locally for Bob, we can run: images). All the instructions to install and run the Tezos 3To avoid to download a fake chain, it is necessary to carefully check that software from source or from docker can be found at the block hash of the imported block is included in the chain. However, we http://tezos.gitlab.io/master/introduction/howtoget.html. do not detail the procedure here. t-c gen keys bob the current counter and compute a new counter (by incrementing the current one) to forge a new operation. In order to test the network and help users get familiar If the new operation has an incorrect counter, it can be with the system, one can obtain free tokens from a faucet4: ignored, or delayed. The following command gives the https://faucet.tzalpha.net/. This service will provide a simple current counter for Bob’s account. wallet formatted as a JSON file. The account can be activated for an identity using: t-c rpc get /chains/main/blocks/head/context/ t-c activate account alice with " ֒→ contracts/BOB/counter "tz1__xxxxxxxxx__.json →֒ 2) For signature check of the incoming transaction, it is We can now check the balance of this account using: mandatory to verify that the sender public key is known t-c get balance for alice on the blockchain. It is time to try to transfer some tokens from one account to t-c rpc get Alice Bob /chains/main/blocks/head/context/ another. To transfer 1 token from ’s account to ’s ֒→ contracts/BOB/manager_key one, we can run 3) To make sure that the transaction will be added into t-c transfer 1 from alice to bob --fee 0.05 the blockchain, we have to make sure that the node is The -fee argument stands for the fees associated to an bootstrapped (ie. that it is synchronized with the other operation in order to encourage bakers to include our operation nodes in the system). in a block. To be sure that the operation is well included in the t-c rpc get /monitor/bootstrapped chain, it is advised to wait 60 blocks (~60 min) to consider it as a valid transaction: 4) Some values have to be given to the transaction operation, in particular the gas_limit and storage_limit (see t-c wait for
model for most operations, but with high-level data structures 5 AMOUNT;
(such as maps, sets, lists and algebraic data types) to help the 6 # amount:(name,storage)
writing of smart contracts. 7 PUSH mutez 5000 ;
The operations – i.e. Tezos transactions (including calls 8 # 5000:amount:(name,storage)
to other contracts), contract creations and delegate setting – 9 IFCMPGT{PUSH string "stingy !" ; will only be executed after the program returns. This prevents FAILWITH}
reentrancy bugs (which are hard to spot and have costs millions 10 {};
and provoked the hard fork on Ethereum after the DAO 11 # (name,storage) attack). We will discuss contract interaction with an example hereinafter (IV-C4). AMOUNT pushes on the stack the number of tokens received The type of each instruction describes the states of the stack from the contract caller, PUSH 'a cst pushes the given before and after the instruction. For example, the instruction constant cst of type 'a on the stack. IFCMPGT is a DUP has type 'a:'S →'a:'a:'S meaning that when macro which compares the two numbers on top of the stack starting from a stack whose top element has type int, the (removing them in the process) and if the first element was duplication of the top element leads to a stack with one more greater it executes its first parameter, otherwise the second. element of type int on top of it (i.e. int:int:'S). Thus If payment is sufficient, we prepare the stack by duplicating the type checking of the contracts ensure that no instruction the pair holding the parameter and the storage, the first (name, can failed because of a malformed stack. map) pair will be consumed by GET to obtain the current While the type of the Michelson instruction is polymor- number of votes, while the second will be used to produce the phic, the type of contracts arguments and storage have to new map. be monomorphic. This is partly to keep the type checking 12 DUP; simple enough to be done efficiently: contract type checking 13 # (name,storage):(name,storage) consumes gas and has to be efficient. Rather than going into the details of all the language To get the value of interest from the storage we first destruct instructions, we will provide here two programs examples. The the pair to get a stack with the key on top and the map beneath, interested reader can find the full description of the language and then we apply the GET instruction. in the Tezos documentation [12]. 3) A voting contract: As a first example, we will describe 14 UNPAIR;GET; a voting contract. The use cases for such a contract range 15 # (Some current | None):(name,storage) from voting for your favourite supercomputer in a TV show, We get the current count for the voted name or None if the to registering vote for important decisions in a decentralized key was not in the map. If the count is some integer value, infrastructure. The first one is a bit simpler to implement than we add 1 to this value, if not we fail because the vote is for the second as we don’t have to check the identities of the an unknown name. voters, so we will focus on this: an open vote with a fee, to determine the preference of the voters in a fixed list of choices. 1 IF_SOME In the following lines, we will present an abstraction of the 2 {PUSH int 1;ADD;SOME} state of the stack with a comment (prefixed by #) after each 3 {PUSH string "Unknown supercomputer"; relevant block of code. FAILWITH}; We start with a storage which holds the names that voters 4 # (Some current+1):(name,storage) are allowed to vote for, associated with the number of votes We now reorder the elements to prepare the stack to use they received. We start our program by declaring the type of UPDATE in order to update the map with the new count. DIP the storage: a map from string to int. allows to work on the element below the stack top, SWAP 1 storage (map string int); exchanges the two top elements of the stack. 1 DIP{UNPAIR}; SWAP; 6 (big_map
2 # name:(Some current+1):storage 7 (timestamp :lookup_key)
3 UPDATE; 8 (nat :rain_level))
4 # updated storage 9 (address :oracle_manager) ) ; We get a new storage, that we pair with an empty list of The code separates the parameter from the storage and then operations to match the return type of the contract, a pair (list checks with IF_RIGHT whether the call is an update (right of operations, storage). of the or type) or a client query (left of the or).
5 NIL operation ; PAIR 1 code {
6 # (nil, updated storage) 2 UNPAIR;
7 } 3 # parameter:(map,oracle_addr)
4 IF_RIGHT { # feeding the oracle with data This rather simple program can be extended in many ways. 5 # (timestamp,level):(map,oracle_addr) For example, a deadline for the vote could be fixed by storing the end date in the storage and comparing it to the value For data update, we first check that the data are indeed pushed by NOW on the stack. Or we could grant the right provided by the registered manager, and fail if it is not the to add new names to the map for voters transferring a bigger case: amount to the contract. Finally, we could store the addresses 6 DIP { of voters (obtained with the instruction SENDER) and reward 7 UNPAIR;SWAP;DUP;SENDER ; the voters who voted for the winner. 8 # sender:oracle_addr:oracle_addr:map All these improvements are left as exercises for the inter- 9 ASSERT_CMPEQ; SWAP ested reader. 10 # map:oracle_addr 4) Inter-contract calls: As stated before, to prevent reen- 11 }; trancy bugs, calls to other contracts are performed at the end 12 # (timestamp,level):map:oracle_addr of the current contract execution, thus to emulate a procedure call expecting a return data, inter-contract calls will have to The map is then updated with the provided values: use callbacks. 13 UNPAIR; DIP{SOME};UPDATE; Let us take as an example an insurance contract A, which 14 # map:oracle_addr calls a meteorological oracle contract B, with a given param- 15 PAIR ; NIL operation ; PAIR eter like a date to obtain a related data (say the hydrometry 16 } of the given date). The contract A will pass to B a callback identifier, like the insured address, B will now call A with If the call is a request from a client we retrieve the data the relevant data and the callback identifier. The contract A from the map and then craft a call to the sender with this can now proceed to the refunding of the legitimate contracting value as parameter. party depending on the data received from the oracle. 17 { We start with a simple oracle which is a contract that just 18 # Getting the data encapsulates a map but guarantees that only a trusted source 19 DIP{DUP;CAR};GET; – whose address is in the contract storage – can modify the 20 # (Some level|None):(map,oracle_addr) map. 21 LEFT unit; For the sake of conciseness, we omit in this contract the 22 # (Left (Some level|None)):(map, usual code allowing the oracle manager, whose key is stored oracle_addr) in the contract, to withdraw the tokens held by the contract. As 23 # preparing the reply to the caller contract will probably be non-spendable in the future, meaning 24 DIP { the owner of the contract will not be able to transfer tokens 25 SENDER; of the contract, only code will, this would freeze the tokens 26 CONTRACT (or associated to the contract. 27 (option(nat :rain_level)) The parameter given to the contract is either a new key-data 28 (unit)); pair to be updated, or a request for the data matching a given 29 ASSERT_SOME; key. 30 PUSH mutez 0
1 parameter (or (timestamp :lookup_key) 31 };
2 (pair 32 # param:0:sender_ctrct:(map,oracle_addr
3 (timestamp :lookup_key) )
4 (nat :rain_level))); 33 TRANSFER_TOKENS ;
34 NIL operation; SWAP;CONS;PAIR and the storage is a map together with the manager key: 35 }
5 storage ( pair 36 }; We can now define our insurance contract. Its parameter 12 # Setup the transfer, then rework type has to be the type expected by the oracle (The one used the stack to satisfy the return in the oracle transfer). In this small example it is easy, but type for more general-purpose oracle interacting with more general 13 NIL operation ; SWAP ; CONS ; purpose client contract, the later won’t be able to have all 14 PAIR the same type, so the usual mechanism is to originate a proxy 15 } contract whose type satisfies the oracle requirement and which Else the call triggers the call to the oracle. can relay the calls between the oracle and the client contract. We will assume here that the insurance contract is issued for 16 { DROP; #dropping Unit a one-time insurance: given a rain level threshold at a certain 17 DUP;UNPAIR;CAR; #getting key point in time, it will redeem one or the other of the registered 18 LEFT (pair (timestamp :lookup_key) addresses of the contracting parties. (nat :rain_level)); The contract can be called by anyone with Right Unit 19 DIP{PUSH mutez 1000}; # pushing the to trigger the redeeming mechanism or by the oracle with fee for the Oracle Left (Some level) (callback). 20 TRANSFER_TOKENS; #calling the oracle 1 parameter 21 NIL operation; SWAP; CONS; PAIR
2 (or (option(nat :rain_level)) unit); 22 }
23 } The storage holds the contract parameters: timestamp at which the rain level should be checked, rain level threshold, D. Contract origination and call redeeming addresses and address of the oracle to consult. To originate the voting contract for a vote on your favorite 4 storage supercomputer, we can use Alice’s account with the following 5 (pair command: 6 (pair t-c originate contract vote\ 7 timestamp for alice transferring 0 from alice \ 8 (pair running ./vote.tz \ 9 (pair --init\ '{ Elt "Sierra" 0 ; Elt "Summit" 0 ; 10 (contract %under_key unit) Elt "Sunway" 0 ; Elt "Tianhe-2A" 0 }'\ 11 (contract %over_key unit)) --burn-cap 1 12 (nat :rain_level %threshold)))
13 (contract %oracle_contract The elements of the storage have to be in alphabetical order.
14 (or Then we can vote for Summit, using the following transac-
15 (timestamp :lookup_key) tion: 16 (pair (timestamp :lookup_key) ( t-c transfer 0.005 from bob to vote\ nat :rain_level)))) --arg '"Summit"' --burn-cap 1 17 ); If we issue the transaction with a 0.001 instead of 0.005, The code inspects the given parameter, if the parameter is the transaction will fail, so we will keep the 0.001tez but we Left (Some level) then we first check that the sender will loose the fees for the baker. is indeed the oracle and then proceed to the redeeming: To test our Oracle/insurance example, we first originate the oracle, as we need to initialise the insurance storage with the 1 code KT1 address of the oracle. This address is generated when the 2 { UNPAIR; contract is originated. 3 IF_LEFT # callback The initial storage use the address of Alice, tz1_XXXX, 4 { DIP{DUP;CDR;ADDRESS;SENDER; as oracle manager, meaning that only transactions initiated by ASSERT_CMPEQ}; Alice can add data to the contracts map. 5 # OK it comes from the Oracle t-c originate contract oracle\ 6 ASSERT_SOME ; for alice transferring 0 from alice\ 7 #Ok the oracle has data for the running ./oracle_ok.tz\ timestamp --init 'Pair { } "tz1_XXXX" ' --burn-cap 1 8 DIP{DUP;CAR;CDR;UNPAIR;SWAP}; The origination receipt gives us the contract address, or we 9 IFCMPLT {CAR %under_key} {CDR % can retrieve it later with the client: over_key}; t-c show known contract oracle 10 # We selected contract which receive tokens Let say the address of the contract is KT1_YYYY, we now 11 BALANCE; UNIT ; TRANSFER_TOKENS; can originate our insurance: t-c originate contract insurance \ Origination: operation to create an account that can contains for bob transferring 100 from bob\ a contract or be delegated running ./insurance.tz --init\ PoS: Proof-of-Stake 'Pair (Pair "2019-05-07 23:22:25+00:00" Pow: Proof-of-Work (Pair (Pair "tz1_AAAA" "tz1_BBBB") 10)) Roll: amount of tokens used to determine delegates’ rights KT1_YYYY' RPC: Remote Procedure Call Self-amending: ability to update itself seamlessly Alice’s account can feed the oracle contract with data: Smart contract: originated account which is associated to a t-c transfer 0 from bootstrap1 to oracle Michelson script --arg 'Right Stake: amount of token (Pair "2019-05-07 23:22:25+00:00" 15)' Storage: blockchain data necessary to run a node and we can check that the data is indeed in the storage of Sybil attack: take over the network by flooding malicious the contract by inspecting it: identities t-c get script storage for oracle Token: unit of value Tz1: Tezos implicit account address Finally anyone can trigger our insurance: KT1: Tezos originated account address t-c transfer 0 from charlie to insurance REFERENCES --arg 'Right Unit' --burn-cap 1 [1] L. Goodman, “Tezos – a self-amending crypto-ledger,” The receipt shows that: https://www.tezos.com/static/papers/white_paper.pdf, 2014. • the insurance contract makes a transfer to the oracle [2] S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” https://bitcoin.com/bitcoin.pdf, 2008. • the oracle makes a transfer back to the insurance contract [3] G. Wood, “Ethereum: A secure decentralised generalised transaction • the insurance contract makes a transfer to the registered ledger,” http://gavwood.com/paper.pdf, 2014. contracting address [4] S. King and S. Nadal, “Ppcoin: Peer-to-peer crypto-currency with proof- of-stake,” self-published paper, August, vol. 19, 2012. [5] L. Lamport, R. Shostak, and M. Pease, “The Byzantine generals GLOSSARY problem,” ACM Transactions on Programming Languages and Systems Baker: entity responsible for selecting operations to produce (TOPLAS), vol. 4, no. 3, pp. 382–401, 1982. [6] J. R. Douceur, “The Sybil Attack,” in International workshop on peer- a block in Tezos to-peer systems. Springer, 2002, pp. 251–260. Block: set of operations, aggregated in the blockchain [7] X. Leroy, D. Doligez, A. Frisch, J. Garrigue, D. Rémy, and Blockchain: distributed database formed as a list of blocks J. Vouillon, “The OCaml system release 4.07: Documentation and user’s manual,” Inria, Intern report, Jul. 2018. [Online]. Available: Client: entity responsible for interacting with a node https://hal.inria.fr/hal-00930213 Context: Ledger’s state (accounts balance, contracts, ...) [8] J. K. Zinzindohoué, K. Bhargavan, J. Protzenko, and B. Beurdouche, Cycle: set of consecutive blocks “Hacl*: A verified modern cryptographic library,” Cryptology ePrint Archive, Report 2017/536, 2017, https://eprint.iacr.org/2017/536. Delegate: entity to which an account has delegated stake [9] K. Bhargavan, A. Delignat-Lavaud, C. Fournet, C. Hritcu, J. Protzenko, Endorser: seal of approval for a block T. Ramananandro, A. Rastogi, N. Swamy, P. Wang, S. Z. Béguelin, Liveness: mandatory property allowing the system to progress and J. K. Zinzindohoué, “Verified low-level programming embedded in F*,” CoRR, vol. abs/1703.00053, 2017. [Online]. Available: Miner: entity responsible for selecting operations to produce http://arxiv.org/abs/1703.00053 a block [10] The Coq Development Team, “The Coq Proof Assistant,” Node: entity responsible for connecting to a Tezos network http://coq.inria.fr. [11] “The Tezos Developer Resources,” http://tezos.gitlab.io/master/. Operation: transforms the context [12] The Tezos Development Team, “Michelson Reference Manual,” Oracle: off-chain third party that can deliver data http://tezos.gitlab.io/master/whitedoc/michelson.html.