Hey folks,
This is the first in a series of blog posts updating you about the state of development. They will serve as updates on the code that has reached master within Tezos. In the dev updates, Arthur talks about what people are working on. The format of these posts is going to be a little different. I'm going to talk about code as it gets merged, which happens after it's been reviewed and is running on the zeronet, so these posts won't match the dev updates too often. I won't include all the MRs, just a few that seem interesting. If you have any technical questions, just send me an email.
In this post, I'm also covering a couple of MRs that probably aren't getting merged in the forseeable future so that if you see them on the GitLab, you won't be surprised.
There's a lot to unpack in this MR. I'm going to focus on the two most interesting changes that relate most closely to the Proof of Stake (POS) algorithm. See the MR for the full list.
Two operations are added to this MR. For context, there are currently operations to originate a contract, make a transfer, propose an upgrade, set the POS delegate, and a few others (see operationrepr.mli for the complete list). The new operations have to do with preventing bakers from misbehaving (read cheating). The POS algorithm assigns the right to bake and endorse each block to different bakers. However, without denunciations, nothings stops you from baking multiple blocks at each level or endorsing multiple blocks. If people were able to do this, the block scoring mechanism would break down because there is no clear way to differentiate between two blocks baked by the same user in the same slot and endorsed by exactly the same people. To prevent this, denunciations allow anyone to call out the cheating. Both endorsing and baking a block require the user to cryptographically sign the header. If anyone becomes aware that a user has endorsed or baked two blocks at the same level, they can broadcast the two signatures. Anyone can verify that the user has signed the information and, once the denunciation operation is included in a block, the offending baker/endorser loses their bond.
Similarly, when you take a roll snapshot matters. These snapshots are used to calculate how large each bakers' stake is for a given cycle. Because bakers with larger stakes will be awarded more baking rights and claim more block rewards, they are incentivized to make sure they have the largest possible stake at the time of the snapshot. A baker can manipulate this by purchasing a large number of tokens right before the snapshot is taken and immediately selling them afterwards. This would enlarge their stake for an entire cycle and create needless churn and strain. By taking multiple snapshots and randomly choosing between them makes this much harder. A baker cannot know exactly when to make this purchase, which makes this strategy less effective. It is possible to take a snapshot after every block, however this would be memory intensive, so the snapshots will be taken less frequently.
Last fall, we switched the build system of Tezos over to Jbuilder/Dune (they're in the process of changing the name). Dune is a build system for OCaml that has a number of advantages over the previous Makefile-based build system. Mostly, it speeds up build times and makes it easier for Tezos to be split into different packages. Even though Dune is now used in more than half of all Opam packages, it's still in beta, which means that they're still making breaking changes. I started this patch before hitting some walls from a change made to Dune that caused it to not include the standard library in the library search path. Grégoire fixed the issues and added commits to change how the build and deploy process works.
Since this MR was created, the Dune folks have released their 19th beta, which Tezos is now using. The beta 19 updates did not seem to break anything inside of Tezos. That change can be seen in this MR, which was manually merged to master.
This fixes a bug caused by OCaml 32 bit integers. In 32 bit OCaml, integers max out at 2^31 - 1. As Tezos can be compiled with both 32 and 64 bit OCaml, we need to keep integer literals in this range. This MR makes sure that the constant is within the required range. This MR was the result of a bug report from someone in the community. If you see a bug in Tezos, please report it on our issues page.
I've included these in case anyone becomes curious about them. They're likely to be around the Tezos GitLab for a while. If you have a strong use case for either of these features, please reach out. There was hesitance to include these Michelson instructions because we weren't sure if we want to support them long-term.
Around five months ago, we were talking about whether Michelson needed additional operations on strings beyond concatenation. We got far enough that I wrote the code to implement it, but we figured it would get merged when (and if) someone came up with a good use case. If you have one, feel free to reach out. This MR is stale enough that it would need quite a bit of rebase work to make it mergable into master.
This was another area of debate. We realized that it's not actually possible to compare to contracts for equality without first hashing them, which is convoluted. Contract equality checks are important if you want to identify users by the contract from which a transaction originated. In many ways, this approach to authentication has advantages over sending signed messages because it creates an API that can called from another contract on the blockchain. This MR didn't get merged because we kept talking about implementing some sort of untyped contract handle. The code is still hanging around in the MR list, but I don't think it's going to get merged before the launch.