Nomadic Labs
Nomadic Labs
Mainnet release to patch Babylon

During the testing phase of protocol Babylon 005_PsBABY5H, we discovered a bug affecting bigmaps in Michelson smart contracts. The bug is corrected in a new version of Babylon, 005_PsBabyM1.

How to proceed

The bug is not critical but causes a significant performance degradation for newly created smart contracts and an incorrect behavior for existing ones using big maps. More details on the nature and effects of the bug can be found in the protocol documentation page.

During the upcoming promotion vote period, we propose two options. The first obvious possibility is to vote Nay so that the current Athens protocol will proceed to a new proposal period. Protocol 005_PsBabyM1 will then be proposed and we will continue with a normal voting procedure. As usual the voting procedure will last 3 months if each voting period is successful.

The second option is for users to download a new version of the Tezos node that, in case of a positive promotion vote, will activate the corrected protocol Babylon 005_PsBabyM1, instead of the defective 005_PsBABY5H. Note that in case of a negative vote this new release of the Tezos node will simply continue to run Athens as expected.

The advantage of the second option is to save the time of a full voting procedure to simply fix a bug. However it is up to the community to decide which option to take.

We do our best to prevent bugs from slipping inside our releases but unfortunately, as with any complex software, there is always a small chance of missing something. This episode proves once again the importance of having a thorough voting and testing procedure.

The patched protocol Babylon 005_PsBabyM1

As with any protocol release it is important to inspect the sources behind a hash. In this case the diff with respect to 005_PsBABY5H consists of two lines, one to fix the bigmap bug described above and one to fix an unrelated problem in an RPC call.

The source of the new Babylon can be found in this tar archive and as usual you can recompute the hash using

mkdir proposal && cd proposal
curl https://blog.nomadic-labs.com/files/babylon_005_PsBabyM1.tar | tar -x
tezos-protocol-compiler -hash-only babylon_005_PsBabyM1/lib_protocol

The result should be PsBabyM1eUXZseaJdmXFApDSBqj8YBfwELoxZHHW77EMcAbbwAS.

diff --git a/src/proto_alpha/lib_protocol/script_ir_translator.ml b/src/proto_alpha/lib_protocol/script_ir_translator.ml
index 5ad517ab4..b73d610ba 100644
--- a/src/proto_alpha/lib_protocol/script_ir_translator.ml
+++ b/src/proto_alpha/lib_protocol/script_ir_translator.ml
@@ -1038,7 +1038,7 @@ let has_big_map
     | Bool_t _ -> false
     | Lambda_t (_, _, _) -> false
     | Set_t (_, _) -> false
-    | Big_map_t (_, _, _) -> false
+    | Big_map_t (_, _, _) -> true
     | Contract_t (_, _) -> false
     | Operation_t _ -> false
     | Chain_id_t _ -> false
diff --git a/src/proto_alpha/lib_protocol/script_interpreter.ml b/src/proto_alpha/lib_protocol/script_interpreter.ml
index 86d5dde53..3e4917b1a 100644
--- a/src/proto_alpha/lib_protocol/script_interpreter.ml
+++ b/src/proto_alpha/lib_protocol/script_interpreter.ml
@@ -978,7 +978,7 @@ and interp
           log := (code.loc, Gas.level ctxt, stack) :: !log ;
           return_unit
     end >>=? fun () ->
-    step ctxt step_constants code stack >>=? fun (Item (ret, Empty), ctxt) ->
+    step ?log ctxt step_constants code stack >>=? fun (Item (ret, Empty), ctxt) ->
     return (ret, ctxt)

 (* ---- contract handling ---------------------------------------------------*)

Cortez security by using the Spending Limit contract

In this most recent blog post we discuss how to benefit from the secure enclave using the Daily Spending Limit smart contract.

My wallet, my crypto When holding a cryptocurrency, one needs a safe and secure wallet to store it. Wallets are used to store, receive, or spend cryptocurrencies. They work by keeping private keys to themselves and using them to sign transaction from the corresponding public keys. A public key is used to send assets to the corresponding destination, whereas a private key is used to send assets from your corresponding wallet. Addresses are uniquely defined as a...

Read More
Babylon update instructions for delegation wallet developers

How to update the delegation feature of your wallet for 005 (aka. Babylon)

Introduction Tezos wallets usually feature management of scriptless originated (aka KT1) accounts used to delegate tokens. This document details the steps needed for wallet developers to update their applications in anticipation to the breaking changes in the Babylon protocol update. See also cryptium’s migration guidelines and Babylon’s documentation for more technical details on the Babylon update. The Babylon protocol update brings two big changes to the way delegation can be implemented. First, implicit (aka tz) accounts can now directly delegate their tokens (see relevant...

Read More
Babylon: Proposal Injected!

EDIT (August 2, 2019): The updated Babylon proposal has been injected by Cryptium Labs. Its hash is PsBABY5HQTSkA4297zNHfsZNKtxULfL18y95qb3m53QJiXGmrbU. The instructions contained in this post have been updated accordingly. Cryptium Labs just injected the hash of our new joint proposal: Babylon. This triggers the beginning of the third on-chain vote to amend Tezos. This process could end in the successful migration from current protocol Athens in about three months, if the participants decide so. This update is joint work with Cryptium Labs, with contributions from...

Read More
Michelson updates in 005

Changes in Michelson As hinted at in a previous blog post, we’ve been working on improving different parts of the protocol, including our favourite smart contract language: Michelson. The changes made to Michelson in this proposal intend to simplify smart contract development by making the code of complex contracts simpler and cleaner. In particular: smart contracts now support entrypoints contracts can now create, store and transmit as many big_maps as they want comparable types are now closed under products (i.e. the pair constructor) a new instruction, CHAIN_ID, allows...

Read More
Analysis of Emmy+

Note: This analysis was done with the help of Arthur Breitman and Bruno Blanchet (Inria). The code used for the analysis can be found at this url. We have recently announced Emmy+ an improvement of Emmy, the current consensus algorithm used by Tezos. In this blog post, we perform a brief analysis of Emmy+. Disclaimer: We emphasize that this is not a complete analysis; in particular, we do not present any security proofs. Also, the...

Read More
An indexer for Tezos

We are happy to announce that the indexer for Tezos we have been working on is ready for beta-testing and available here. But first… What is an indexer, and what is it useful for? Mainly, indexers fill a void by providing information that’s not directly available from the node’s RPC interface. But then why don’t nodes provide these RPCs in the first place? That’s simply because when you design and implement your node, you want to provide just what is necessary, focus...

Read More
Meanwhile at Nomadic Labs #3

Another update on the many projects we have been busy working on. Most of the following topics will be subject of more in-depth posts of their own. Protocol The consensus team is finishing their analysis of selfish baking on Emmy+ and tweaking the constants of the protocol accordingly. At the same time work on our version of Tendermint is progressing to the point of having a proof of concept protocol to play with. The protocol team has been steadily reviewing and testing...

Read More
How to write a Tezos protocol

A Tezos node is parameterized by a software component called an economic protocol (or protocol for short). Different protocol implementations can be used to implement different types of blockchains. This is the first post of a tutorial series on how to implement such a protocol. We will see how to write, compile, register, activate and use an extremely simple protocol. By doing so, we will also start to explore the interface between the protocol and the node (more specifically the shell component of...

Read More
Emmy+: an improved consensus algorithm

Underlying the Tezos network is a consensus algorithm, which, for the ease of reference, we will call Emmy. Consensus ensures that participants agree on the same blockchain and on its state. The ideas behind Emmy are described in the white paper and the specifics to its implementation can be found in the documentation. We recall that Emmy is a PoS based consensus with a use of endorsements to speed-up confirmation times and reduce...

Read More
  • 1
  • 2

Receive Updates

ATOM

Contacts