StarkNet roundup #54

Weekly summary of all things StarkNet

February 28, 2023

This newsletter is made possible thanks to Braavos, the wallet loved by the tech community.The Braavos Wallet account contracts and fast ECDSA implementation are now open sources on GitHub, which allows the community to access the source code, review it, and benefit from a secure solution.Braavos is dedicated to making cryptocurrency accessible, secure, and innovative and is proud to be part of the open-source community on StarkNet. With your support, the Braavos wallet is expected to continue to evolve and improve.

Welcome to the 54th edition of my weekly comprehensive StarkNet summary. The previous update can be found here. 👇🏻

Would you like to sponsor this newsletter? Reach out to me.

If you enjoy this newsletter, don’t forget to subscribe. It’s free!

Let’s get into this week’s news! 💪

Protocol & dev tool updates

Media highlights

Ecosystem Highlights

Image

Ecosystem stats

StarkNet Community & Shamans Highlights

This post deals with a fundamental design problem for blockchain protocols with proofs 5: the buffer problem. We’ll start by separating it into proactive and reactive problems. Next we’ll discuss their relationship, ending with some thoughts on how to resolve each of them.

The buffer problem: there may be consensus on blocks which are not profitable to prove, resulting in abandoned jobs (“holes” in the forest of jobs).

The name comes from the flow ‘users → consensus → proofs’ in which the consensus layer acts as a buffer between users and provers. Let us distinguish between two challenges underlying the buffer problem.

In practice, the reactive buffer problem may arise due to volatile exchange rates between the token and the fiat used by provers. Specifically, a block may be profitable to prove when it reaches consensus but become unprofitable at a later point in time if the reward depreciates.

An effective proactive solution reduces the scope of the reactive problem: better proactive pricing means fewer unprofitable blocks to deal with.

To discover the market price one can use an algorithmic base fee. The base fee can be set as a lower bound on the prover resource price. (Think 1559 minus tips and minus burn rule.) Overpayment can use static (hardcoded) prices or rely on a price discovery mechanism (e.g base fee). For example, the base fee may be 1 token per unit of resource and the protocol may issue a 10x overpayment of 10 tokens.

We do not expect a proactive solution to entirely prevent the reactive problem. However, a profitable proving business may incentivize provers to occasionally prove unprofitable blocks at a loss for the sake of maintaining the steady flow of profitable jobs.

Heavily discussed StarkNet Improvement Proposals

Useful links & articles

Developer resources

Dates and Events

You can check out all of the past updates here.

None of the content of this newsletter is financial advice. Always do your own research.

Thank you for reading, and see you next week. ⏳

Would you like to sponsor this newsletter? Reach out to me.

Reply

or to participate.