I read the Gobblers contract a while back, and here is a compilation of my notes.

It's not a complete review, but rather the things I found interesting.

kudos to @FrankieIsLost @transmissions11 for the excellent codebase 🔥

►External contracts that are part of the system (e.g., goo) are saved as immutables (e.g., `Goo public immutable goo`)

This is smart because immutables are replaced at deployment time with the value. Thus, they can be supplied from the constructor (dynamic) AND save gas.

► Constants to the system are ALL_CAPITAL

Good visual hack for readability

► Use weird uints for efficient packing in structs

We tend to forget that uint comes in all shapes and forms (e.g, uint96). No need to stick to the usual (uint256, uint128, etc.)

►Use custom errors instead of require

Seems suitable for gas usage and readability.

This should be done in new codebases and should not be introduced in older codebases, where it would coexist with 'require'. As @annascarroll likes to say - "this seems like code-smell."

►Pack the increment of a variable inside something else, like an event emission. That way, you both get the storage variable incremented, and it's used simultaneously by the event.

Ingenius

► Use underflow/overflow to revert to unintended behavior

This, IMHO, hinders *a bit* from the readability since the intended behavior is not clearly defined by a `require` or `if.` With appropriate commenting, it shouldn't be a problem.

► Use `++` operator liberally and in the place of the last expression that uses the variable instead of incrementing on its own
• `array[i++]` will use `i` to access the array and then increment it
• `array[++i]` will first increment and then access the array with `i + 1`

►Use calldata instead of memory. You skip from copying the data in memory, but you have to use data that come from calldata (directly or indirectly).

Although using `memory` is handier, `calldata` can indeed save up some gas. The restriction can be a bit frustrating, though.

►In a loop:
• it's better to store the array item in a memory variable
• define the memory variable once outside the loop (saves about seven gas on every iteration)

►It doesn't use modifiers but instead inlines the access control.

This saves gas, but again in my mind, hinders readability. With modifiers, it's easier to visually group functions for things such as access control or state machine restrictions.

► Saving gas from if statements:
• Use ternary operators in combination with variable definitions
• Use branchless expression via Assembly

I will probably use the compact if and definition. A similar practice is used in Rust. I tend to avoid Assembly.

► Name tests with `FFI` or `Longrunning` so we can filter them out of the CI tests.

e.g `longrunning_testFuzzLiquidation`

►You can pack a variable definition and a check inside the same require.

►Deployment scripts:
• Functionality is implemented in a base contract that uses constructor args to define variables. You create a contract that inherits the base and calls the constructor with different args; thus, the constructors work as a configuration file.

You can read the unrolled version of this thread here: https://typefully.com/odysseas_eth/Yze62K9

Gobblers Solidity notes

I recently talked on @EFDevcon about my learnings from the @nomadxyz_ hack, which saw about $190M in tokens drained from the Nomad Bridge.

Probably one of the most painful experiences I have ever had.

A quick thread 🧵 on how I went from Nomad to Very Mad

1/26

Firstly, a small disclaimer:

The views I express today are my own and do not reflect Illusory Systems (the company behind Nomad)

Feel free to watch the presentation here:

https://www.youtube.com/watch?v=Ow8YXfv02Jo

2/26

Nomad is NOT a bridge.

Nomad has a bridge.

Nomad is an optimistic protocol for interoperability that supports arbitrary messages between domains.

A bridge is just an application on top of a message-passing channel.

3/26

But how Nomad works?

Messages sent from a domain are added to a Merkle Tree. The tree's root compresses the information about whether a message belongs to the tree.

Nomad simply needs to send the root from one domain to another. The messages can be proven on that domain.

4/26

A message is sent from a domain by calling the Home contract. It will add the message to the Merkle Tree, which updates the tree's root.

After the root is relayed to the Replica contract, we wait for the optimistic window and finally can prove and process messages.

5/26

But how does a bridge work?

The user sends native tokens on the sending chain to the bridge. It locks native tokens on the sending chain and mints representation tokens on the receiving chain. These tokens have value only because they can be redeemed for the native ones.

6/26

IMHO, this is why bridges are hacked so often.

They are not only complex systems but also own tons of collateral. They are juicy targets that attract a lot of eyes.

Without collateral, users can't redeem back their representations.

7/26

Root Cause Analysis

A bug caused the Replica contract to fail to authenticate messages properly. This issue allowed any message to be forged.

@coinbase did an excellent incident analysis on this

https://www.coinbase.com/blog/nomad-bridge-incident-analysis

8/26

Currently, the Nomad Protocol is paused.

Restarting the Protocol is easy.

Restarting an under-collateralized Bridge is hard.

We want people to:
a) Collect funds whenever tokens exist in the bridge
b) Collect funds fairly

Follow @nomadxyz_ for updates and design details.

9/26

✅ My Suggestions for protocol devs:

Bismarck said that only a fool learns from his own mistakes. A wise man learns from the mistakes of others, so I would advise you to take note.

10/26

I grouped my suggestions into four categories:

•  Test
•  Observe
•  Engage
•  Communicate

Think of them as multiple defenses of a castle. You layer them properly and hope the attackers won't breach the citadel.

11/26

🛠 Test 🛠

➡️ Testing
• unit tests
• property-based tests
• integration tests
• forking tests
• invariant tests

➡️ Honorable mention
• static analysis
• storage layout inspection

🔥 Use foundry 👇
https://getfoundry.sh/

12/26

In my mind, priority should be in
- Unit Tests
- Property-based tests
- Forking Tests
- Audits

Moreover, I think that protocols should seriously consider."
- fork tests (bugs often require on-chain state to get surfaced)
- invariant tests (provably secure protocol)

13/26

👉 Quick plug

I created a simple script that you can add to your CI and verify that the storage layout of your contracts does not change without you noticing.

**A LOT** of the hacks that happened to upgradeable contracts were due to this.

https://github.com/odyslam/bash-utils

14/26

👁 Observe 👁

If you receive "u up" and aren't already up, it's already too late

15/26

Alerting in web3 is nascent, but it's a solved problem in Web2.

1.  Start with Business Objectives
2.  Define Actionable Alerts
3.  Define Playbook for every Alert
4.  Beware of Alert Fatigue 😴 (ignore alerts)

Read the Google SRE handbook: https://sre.google/sre-book/monitoring-distributed-systems/

16/26

IMHO, we can group on-chain alerting into two large groups:

1. Hereustic-based alerts. Define rules, but require human intervention to interpret
2. Invariant-based alerts. If invariants break, then alert. Mitigation can be automated due to its binary nature (true/false)

17/26

An interesting note about "Invariant-based" alerts:

Interestingly, @rikardhjort from @rv_inc mentioned a similar use of continuous invariant testing as part of an alerting system in his talk "Formal method for the working DeFi dev"

Expect more 🤙

https://archive.devcon.org/archive/watch/6/formal-methods-for-the-working-defi-dev/

18/26

⚔️ Engage ⚔️

It's now the time to manage an incident.

Prepare for the incident. Have explicit ownership of all the deliverables (which should also be precise).

Unless you have simulated it before, you won't react in time under stress and extreme time constraints.

19/26

Read The Anatomy of a Good Emergency Procedure by our good friends at @TenderlyApp and @iearnfinance and adapt it to your organization.

Then run gamedays for the entire org.

http://blog.tenderly.co/what-good-war-room-emergency-procedure-yearn-finance-case/

20/26

🗣 Communicate 🗣

Now that everything is said and done. It's time to face the music.

Although we always have the user in mind, we shouldn't talk to anyone. Not a tweet, not a GitHub commit, nothing.

First, we talk with our legal team.

Then, we talk with users.

21/26

Let's see an example timeline for the first hours/days after the incident:

1. Inform legal
2. Inform users
3. Inform partners
4. Get a chain analytics firm
5. Setup a recovery address
6. Align with legal on a bounty
7. Inform users

🔁 Rinse and repeat steps 1,2,3,4

22/26

A note on chain analytics firms:

They provide valuable information to Legal Enforcement Agencies (which are contacted via your legal team). They also help with asset recovery, as people have a sudden change of heart as LEA zeroes in their real identity. 🤷‍♂️

23/26

Expect Asset Recovery to be a parallel workstream to everything you do. It will continue to consume human resources and capital throughout the following months of operations as you:
• mitigate the hack
• restart the protocol
• figure out the way forward

24/26

I am sure multiple protocols are thinking about the same issues, so I am always looking for cool stuff to collab on and make the space a tiny bit more secure.

I hope I have given you a map you can use as you develop your protocol.  Security shouldn't be an afterthought.

25/26

I feel truly blessed to work alongside @annascarroll , @_prestwich , and the rest of the Nomad crew.

You can be sure that the Nomad team is working overtime to push the protocol forward and restart the bridge.  I couldn't have asked for better teammates.

26/26

You can read the unrolled version of this thread here: https://typefully.com/odysseas_eth/XQskWEh

Nomad: Learnings from the Incident


After taking some much-needed time off, I am stoked to announce that I am joining @nomadxyz_ as a vibes engineer, working towards a cross-chain future founded on the principles that I care most about.

Trustless and Secure.

👇 A thread (like you didn't see it coming)

1/

This thread is divided into two parts:

1) WTF is Nomad?

2) Why I am excited about joining Nomad

2/


Nomad is NOT a bridge.

Nomad is a protocol for sending arbitrary messages between different domains, either L1 blockchains or sidechains, and rollups

Wherever you read chain, think domain

A bridge is an app that uses channels to send tokens from one chain to another

3/

Bridges and channels are often conflated because a bridge is the first and foremost application of a messaging channel.

Nomad is so much more than that.

With Nomad, we can extend any functionality to be cross-chain.

e.g: Vote on one chain and execute proposals on another

4/

The vision is to have a unified protocol that connects any domain with any other domain.

No need for hops between domains and complex representations, as all assets will be able to be directly bridged.

To do that, we need a simple, robust protocol.

We need Nomad.

5/

Generally, there are three kinds of channels

- Light-client: A smart contract verifies block headers from the other domain. => Secure, Fast, EXPENSIVE

6/

- Validators/Trusted: A PERMISSIONED set of validators move messages (or tokens) -> Fast, Cheap, Security low

The main problem with Validator sets is that you can only minimize Trust, but never completely remove it. Both Ronin and Wormhole hacks happened on trusted bridges.

7/

- Optimistic Rollup(ORU) Channels: TIED to their optimistic rollup, secure, slow

8/

Nomad has an Optimistic design:

Relatively slow (faster than ORU), lower security than ORU, LOW complexity, HIGH reusability

(At the end of the thread, I link a couple of resources about our design)

9/

With a focus on low complexity and high reusability, we create an easy-to-reason-about protocol that can rapidly be deployed.

Direct channels mean that messages don't multi-hop to reach their destination, and tokens are directly respresented.

SIMPLE⬆️ => SECURE⬆️

10/

We allow fraud in edge cases that are managed through crypto-economic security while targeting reusability, low complexity, and low cost.

With Nomad becoming THE channel protocol, teams don't have to trust Y number of bridges.

They trust one implementation for all.

11/

This is an important point, as most people prefer to use the native bridge of a rollup for fewer trust assumptions.

But, if they use 5 rollups, they have to trust 5 bridge implementations.

The more domains they want, the more critical a singular implementation is.

12/

📍 HOW Nomad works

It's part of the optimistic family of system designs. It sees some attestation over some fact and if a specific amount of time passes, then it accepts it as valid.

13/

The sending chain is the source of truth and contains the “Home” contract where messages are enqueued. Messages are committed in a Merkle tree. The root of this tree is signed by the updater and relayed to the receiving chain.

14/

Any chain can maintain a Replica, which stores the latest Root it knows about. By receiving updates through the Relayer, it can replay all updates and reach the same Root as Home. 

The processor makes sure that updates are processed after the time window elapses.

15/

Fraud can happen on the receiving chain, but you can prove it on the sending chain and the updater will get slashed.

Fraud can't be hidden and we only need a single honest party for the Updater to get slashed and the system to be halted.

Fraud = Costly. Public. Blocked.

16/

Nomad is comprised of smart contracts and off-chain rust agents that work in tandem.

Main contracts:

🏡 Home.sol: Source of truth for all messages sent FROM the domain.

👥 Replica.sol: Source of truth for all messages received FROM a domain to the destination domain.

17/

📠 Router.sol: Application-specific, encodes/decodes messages passed in the channel for that app.

It sits between the app and either Replica or Home.

Nomad channels are like internet cables, raw. The router makes sense of the signal, converts it to data, and routes it.

18/

Offchain Agents

Updater: poll Home and update source of truth (SoT) with new messages

Relayer: Watches Home SoT and adds to Replica queue

Processor: After time passes, updates Replica SoT with messages from the queue

Watcher: polls for fraud in Relay and reports to Home

19/

An overview of the architecture, with a supposed message flying from Ethereum to Polygon and back to Ethereum.

The numbers on the lines signify the order of participation of each entity.

Watcher's step is optional (only if fraud occurs, thus between 2 and 3).

20/

For every Home contract, there is an Updater that “updates” the Root, a Relayer that relays the new Root to every Replica, and a Watcher.

For every Replica contract, there is a Processor that updates the Replica root after the time window.

21/

Now, let's see the above use-case, but with greater detail:

After I send the message through the Gov Router, an event is emitted by Home that a new message was added to the route.

Updater listens for that event and reacts.

22/

Updater "updates" the Home Root, which in turn is detected by Relayer which propagates the change to the Replica. 

Note that “dispatch” in the previous flow does not trigger an Update of the Root. The updater can wait for multiple queued messages and "batch" update them.

23/

Next, the processor will pick up the new Root in Replica and wait for the time window.

Once the time elapses, it verifies the messages that it picked through event emission against the new Root.

Finally, Replica calls the respective routers and sends the raw messages.

24/

The above flow was the happy path, aka how the system will work if everything goes as planned.

There are two types of fraud:

- Improper Update
- Double Update

Moreover, we are actively working on our Fraud Recovery mechanism and you can expect many things in the future.

25/

Improper Update

The Updater signs a fRoot that wasn't queued, thus including fake messages and it to the Replica

The Watcher

a) submits the fRoot + Updater's sig to Home. Updater gets slashed, and Home shuts down

b) removes Replica from the Registry, closing the channel

26/

Double Update

Double Update can be proven in both Home and Replica.

The watcher submits two roots that share a root, and have valid signatures but are not equal. At some point in the message Tree, there was a fork.

The contract fails and Updater gets slashed.

27/

While the system is now highly centralized, we want to be highly transparent, as we move towards realizing our vision.

Currently, we are finalizing our Governance module, which will enable voters to choose new chains to be added to send and/or receive messages.

28/

Nomad Governance TL;DR:

We define a governor chain where the governance lives. 

That chain MUST have a direct connection to every other chain so that governance proposals can be executed (e.g change x parameter in chain Y).

The chains may or may not have a direct channel.

29/

Moreover, we are working towards decentralizing the operation of our off-chain agents.

In our design, the only permissioned agents are the Updater and the Watcher.

The Updater is bonded so that it honestly updates the Root of the Home.

Watcher is fully trusted (for now)

30/

The Watcher performs two functions, one which is permissionless and one which is not.

a) Inform Home of a fraudulent update in Replica, slashing the Updater. Home can detect fraud.

b) Halt the Replica. As it can't detect fraud, it assumes that the Watcher is honest.

31/

In the future, we want to improve the design and make Watcher a permissionless entity that anyone can run, but are incentivized to be an honest actor.

We have a couple of designs in mind, so stay tuned anon for a thread in the future ⚡️

We are on it, anon.

32/

When I started talking with the team, I immediately knew that there was something special about it.

While @pranaymohan talked about the state of affairs in bridging and the opportunity with Nomad, @barbaraliau underlined the challenges that the team is tackling.

Honesty ✅

33/

But it's not only about honesty. It's also about pragmatism.

You can't go where you want, if you don't know where you **are**.

Realizing a vision is like a vector, the direction is equally important to speed.

@annascarroll gave me confidence that we will get there.

34/

Then, I started reading about the protocol and I found the same characteristics.

While extremely early, the team has ensured that the documentation serves as a true source of truth for the state of the protocol.

It's not about benefits, but tradeoffs.

35/

There are BILLION dollar projects that use marketing-speak in the dev docs, omitting questionable design decisions and real-life data.

But, Nomad is different.

We don't need to hide anything.

We trust our design decisions and our ability to tackle their challenges.

36/

In Nomad I will be initially helping at the protocol level, formalizing the protocol, and (obviously) porting our test suite to Foundry. 

At the same time, I plan on familiarizing myself with the codebase of the  Rust Agents, enabling me to contribute there as well.

37/

Apart from that, one of my goals is to maintain a "state of affairs".  

An accurate 1-pit stop for developers and users that want to know about our protocol.

Where we excel, where we suck, and what we want to improve. 

I want Nomad to be an example to follow.

38/

Ah, did I mention that Nomad just raised 💲22M to build the protocol for a cross-domain future? 

Yup, it did.

https://twitter.com/nomadxyz_/status/1513891049906872325

39/

Dive deeper into Nomad:

https://docs.nomad.xyz/#how-nomad-passes-messages-between-chains

https://github.com/nomad-xyz/monorepo

40/

Check out the data for yourself:

https://dune.xyz/0xroll/Nomad-Bridge-Ethereum

Try out our bridge:

https://app.nomad.xyz/

41/

A great talk about bridges and the tradeoffs with an Optimistic design, by @_prestwich

https://www.youtube.com/watch?v=ZQJWMiX4hT0

You can read more about the Optimistic design in this great post by @ConnextNetwork 

https://blog.connext.network/optimistic-bridges-fb800dc7b0e0

42/42

You can read the unrolled version of this thread here: https://typefully.com/odyslam_/R7s2z9E