Starknet Engineer Core Unit - December update

Starknet Engineering Core Unit Month in Review: December 2021

This post summarises the tasks, work, and activities of the Starknet Engineering Core Unit for the month of December. The short summary is that we shipped a first version of the Starknet bridge contracts, we will add events to those contracts once they are available on Starknet. We worked on sharing knowledge about Cairo with relevant stakeholders, and we planned for the implementation roadmap for phase II (wormhole design) with a focus on fast withdrawals.

First version of the Starknet bridge contracts

You will find the github repo to our bridge contracts here. The main challenges of writing those contracts have been:

  • Understanding the difference between Starknet and Optimism and the implications for a scenario where the sequencer is censoring transactions
  • Understanding the features that are currently available on Starknet and what will be available in Q1 and Q2 of 2022
  • Defining a mitigation process in case Starknet goes down or the sequencer is malicious. We opted for providing MakerDAO the ability to redistribute funds on L1 manually in case such an event was to occur

Audit with ChainSecurity

  • We went through a first audit with ChainSecurity which turned out to be very useful with great catches from the team. You will find the audit report publicly available here
  • As events are planned to be released on Starknet at the end of January, we will incorporate into our contracts code, along with some refactoring. We will ask for an additional audit of the contracts early February

Code walkthrough with the Protocol Engineering Core Unit

  • In order to assure our code is peer-reviewed and to prepare for the wormhole implementation on Starknet, we organized two code walkthroughs with the Protocol Engineering team
  • We have more walkthroughs planned for January, with a side-by-side comparison of the optimism bridge code and the Starknet bridge code

Front-end integration and public launch

  • We synchronized with the Starknet team to integrate our bridge to their bridge interface
  • The interface will require the user to connect with both an Ethereum wallet and ArgentX (Starknet wallet)
  • We are aiming at launching the front-end, coupled with a PR push around the third week of February

Wormhole implementation preparation

To prepare for phase II of our mandate, the wormhole design, we pursued the following activities:

  • We studied and analyzed the wormhole design produced by the Protocol Engineering Core Unit
  • We studied the first chunk of code submitted for audit by the Protocol Engineering Core Unit
  • We defined a January roadmap to start implementing the Starknet version of the wormhole design, starting with fast withdrawals
  • We submitted MIP40c3-SP47 to request a budget for phase II
  • We organized discussions with delegates to hear out their comments and concerns about the Starknet implementation of the wormhole design
9 Likes

Hey folks—just simple questions here. Being that StarkNet is still centralized, is L1escrow Permissionless, no keys? Or it is permissioned and forceWithdaw is the equalizer for users who are censored?

With regards to minting uncollateralized L2 DAI, you mention that:

Bug allowing direct access to mint method on L2 dai or to finalize_deposit on l2_dai_bridge will result in a creation of uncollateralized L2 DAI. Withdrawal finalization to L1 is expected to take several hours on StarkNet. Maker governance with its 2 day delay won’t be able to respond in time to coordinate preventive action if a malicious user mints uncollateralized DAI on L2 and withdraw DAI on L1.

In case this :point_up_2: happens, is there a “trigger-function” that can alert Maker governance and extent withdrawal finalization to L1 for more than 48 hours? TOL.

With regards to getting Maker Devs up to speed with StarkNet—as we know, Coding dApps natively on L2 requires learning Cairo — wondering if you can provide us with an update on how that’s going.

And last but not least, with regards to Oracle price updates—as you and the entire community knows, managing oracles include dozens of price updates and signatures from various sources to calculate—can you please provide how StarkNet/ValidityRollup help with scaling this issue?

Thanks in advance!

3 Likes

@ElProgreso thank you for those questions, answers in-line below

Q: Hey folks—just simple questions here. Being that StarkNet is still centralized, is L1escrow Permissionless, no keys?

A: Only the L1DAIbridge contract and MakerDAO can call the escrow contract. L1DAI bridge can call the escrow to transfer funds to the users on L1 in case of a withdrawal. MakerDAO can call the escrow contract to redistribute the funds on L1 in an emergency situation (e.g., rollup going down or forced withdrawal being ignored/censored).

Q: Or it is permissioned and forceWithdaw is the equalizer for users who are censored?

A: forceWithdraw is doing the same thing as the function initiate_withdraw on the L2_dai_bridge contract, except that the call is made on L1 so even if it is censored by the sequencer, we can see the call has been made on L1 and the DAO can take action if that request is censored for more than 7 days by the sequencer. forceWithdraw is not a permissioned function, however it will fail if the user does not have a L2 address or is trying to withdraw an amount higher than their balance.

Q: With regards to minting uncollateralized L2 DAI, you mention that:

Bug allowing direct access to mint method on L2 dai or to finalize_deposit on l2_dai_bridge will result in a creation of uncollateralized L2 DAI. Withdrawal finalization to L1 is expected to take several hours on StarkNet. Maker governance with its 2 day delay won’t be able to respond in time to coordinate preventive action if a malicious user mints uncollateralized DAI on L2 and withdraw DAI on L1.

In case this :point_up_2: happens, is there a “trigger-function” that can alert Maker governance and extent withdrawal finalization to L1 for more than 48 hours? TOL.

A: The first line of defense is enough testing, peer-reviews, and comparisons with other rollups’ implementations. A second line of defense is the bridge limit and debt ceiling, limiting the amount that could be maliciously withdrawn. A third line of defense is a bug bounty to assure that there are no bugs inadvertently providing unwanted access to those methods. As you suggest, a fourth line of defense could be an alert mechanism coupled with a circuit breaker. This mitigation mechanism could be implemented for any rollups. I launched the discussion on discord in the public protocol engineering channel.

Q: With regards to getting Maker Devs up to speed with StarkNet—as we know, Coding dApps natively on L2 requires learning Cairo — wondering if you can provide us with an update on how that’s going.

A: We have had discussions on a weekly basis with PECU about trust assumptions before getting at Cairo, and we are revisiting those discussions for fast withdrawals and wormhole teleportation. On Cairo side, we have been doing weekly code walkthroughs in December with the Protocol Engineering team and we will be doing side-by-side comparisons of contracts in January. Bartek gave a presentation last week of the CPU architecture of Cairo to better understand/explain the differences between Cairo and Solidity. Those sessions are typically happening on Thursday afternoons and are recorded, we will discuss the best place to post them, most likely a post from our CU.

Q: And last but not least, with regards to Oracle price updates—as you and the entire community knows, managing oracles include dozens of price updates and signatures from various sources to calculate—can you please provide how StarkNet/ValidityRollup help with scaling this issue?

A: Starknet oracles can be thought of in two contexts: Starknet-based price Oracle service for Starknet (e.g., price oracle for Maker implementation on Starknet), and a Starknet-based price oracle service for L1.

For Starknet oracles, we will build a price oracle service in phase III, when we build MCD on Starknet. Note that we will build with the Oracle team the wormhole oracle before we build the price oracle service. The cost of operating that price oracle can be broken down into L1 cost (proof cost) and L2 cost (transaction fees). The L1 cost is significantly higher than L2 cost and would be expected to be around 300 to 1k gas, i.e., ranging from ~ 100 to 150x cheaper than the current oracle cost.

For L1 oracles, the cost improvement will be in the same range as for the use case above, so that’s very promising. However additional considerations must be taken into account for a L1 oracle service. First, oracles are designed for the worst case scenario and a significant amount of thinking needs to be put in to define emergency cases, including new ones introduced by a new Starknet-based design. Second, given how critical oracles are for Maker, we don’t think an oracle service for L1 is viable until Starknet reaches decentralization. Additionally, the poke method is called roughly every hour, hence such a design can be considered only when Starknet proofs are sent to L1 more frequently than hourly. In terms of high-level feasibility, the decentralization roadmap will start being implemented in Q2-Q3, and more frequent batch updates will also be implemented in the second part of 2022.

cc: @Ohad_Barta_StarkWare @marcandu for the Oracle discussion. They both provided useful detailed gas calculations that I was able to compare

1 Like

Thank you Louis for taking time-out to formulate all the answers to my questions and for re-introducing the idea of a “circuit-breaker” with PECU. Much appreciated.

And last question (promised) I was reading about L1 to L2 messaging, how does StarkNet handle messages when L1 usually waits for x number of confirmations? And get a message getting stuck also cause for funds to get stuck? Thanks in advance!

2 Likes

Thanks @ElProgreso , appreciate your questions

The L1->L2 messaging starts by a call to the Starknet Core Contract on L1. Currently Starknet is not decentralized yet and the sequencer waits to assure that this call is final on L1. When Starknet will be decentralized, sequencers will have a very strong incentive to wait. So to answer your question, everything is done so the L1 call is final and hence a wrong L1->L2 should not be processed by the L2.

There is another case where funds could be stuck in the L1 bridge: if user deposits funds on L1 bridge but the sequencer censors the mint call on L2. This will be solved end of February with the Starknet v0.71 where if the sequencer censors mint on L2, the message is canceled from Starknet Core Contract and funds can be returned to user on L1.

1 Like