Reproduced from https://ex.rs/protocol-level-fees where this blog post was originally published.
The following is a collection of thoughts around fee markets in general and mechanism to fold in transaction fees in a protocol, such as the one outlined in EIP 1559. While EIP 1559 is an Ethereum-specific proposal, the fee market in Tezos, Bitcoin, and Ethereum are essentially similar, making the ideas in this proposal broadly applicable to all three.
Let’s first review how a fee market work, and clear up common misconceptions about fees. Block producers control a scarce resource: block space. Whether this space is expressed in terms of…
This blog post was originally published on https://ex.rs/on-supply-caps/
This blog post expands on a popular Reddit comment on the benefits and drawbacks of supply caps. This topic is particularly interesting as it touches upon many areas of crypto-economic design. It’s also an opportunity to highlight some of the benefits of binding on-chain governance and debunk popular economic fallacies.
A supply cap refers to a permanent limit on the number of units of a cryptocurrency (or coins) that can ever be created. …
I have been compiling some thought from various community members regarding the design of an on-chain treasury for Tezos chains, and what that might look like. Of course, there is already a way of funding various causes through protocol upgrade proposals that slightly inflate their supply. However, this mechanism may not be appropriate for all the type of endeavor that Tezos communities might want to fund. For instance, they may be interested in funding computer science research, open source software development, or even participate in charitable causes such as medical research. …
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.
Users 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…
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…
Bitcoin has mining, Tezos has baking. In Bitcoin, miners compete to publish blocks containing a proof-of-work stamp by repeatedly hashing block headers. In Tezos, block creation is done by bakers. Rather than deriving the right to create a block by finding the solution to a proof-of-work problem, bakers obtain that right when a Tezos token (or rather a roll, see below) they own (or that is delegated to them) is randomly selected to create a block. Since not everyone holding tokens is interested in being a baker, tokens can be “delegated” to another party. The delegate does not own or…
I’ve spoken several times of hash-consing as a way to store contract data efficiently for the Tezos blockchain. Here’s why it’s useful, how it works, and what its limitations are.
Hash-consing in Tezos lets smart-contract seamlessly share data, with no duplication. If two smart contracts store the same table, they are only be stored once. If they store slightly different data, the overlap is also only stored once. This happens whenever two pieces of data are the same, even if by accident.
This has several benefits:
Tezos is a proof-of-stake blockchain with a delegation mechanism. How delegation is handled at the launch of the network could have enduring consequences for the network.
In Tezos’ proof-of-stake mechanism, the keys granting the right to sign blocks (“bake”) are different from the keys granting the right to move tokens. This is a security measure which lets users keep keys in cold storage while participating in the proof-of-stake algorithm. It also enables delegation, whereby the right to create blocks (“bake”) is transferred to a third party, the holder of the delegation key.
How should delegate keys be handled at the…
This post describes a light compilation step to help stack manipulation in Michelson. It’s not critical for the launch, so we aren’t focusing on it in the near term, but I am sure this problem will nerd-snipe a few people, and I’d love to see someone pick it up.
When writing contracts in Michelson, Tezos’ smart contract language, stack manipulation can often get in the way. To get a sense, check out Milo’s contract examples. Splitting pairs, reforming them, re-ordering elements of the stack is time consuming for the programmer, and reduces code readability.
There are, fortunately, three workarounds:
Here is a short video update on Tezos development in the past week. Beware, this was largely improvised and the sound quality is not good. Please bear with us, we do intend to make it more polished next week, but in the meantime this should do.
We’re moving to a new location tomorrow and I’ll post some pictures. Of course, the situation that was brought to light yesterday and the delays it has caused are regrettable, to say the least, but we’re all focused on the positive, which is the continued development and improvement of Tezos.
In the meantime, here’s a photo from lunch.