Sommelier Protocol Team Weekly Update #3

Launch App

Sommelier Protocol Team Weekly Update #3

Welcome to the weekly Protocol team update on the Sommelier protocol upgrades! This is the third week of the Informal's audit and the team's delivery of upgrades to the Sommelier Gravity Bridge.

INFORMAL’S AUDIT ON THE GRAVITY BRIDGE: UNSAFE ERROR HANDLING IN THE ORCHESTRATOR

The orchestrator is a single binary that combines the Eth Signer, Oracle, and Relayer for ease of use by the Validator Operator. One issue that surfaced from Informal’s audit is handling of unsafe error in the Orchestrator.

Since the Orchestrator is built with Rust, there’s constant use of panic causing statements like unwrap(), panic!(), assert(), assert_eq(), and expect() for error handling. Although these methods are safe in most cases, there are some cases where it is not safe. For instance, the network errors or misbehavior/bugs in other Gravity Bridge components can invalidate these error handling statements, causing a panic.

The auditor classified into three categories some cases where panic causing statements can be invalidated. Let’s take a look at these categories and how the Sommelier protocol team resolved them.

Assertions that depend on other Gravity Bridge components

Assertions on components that depend on other components can be unsafe. For example, it is difficult to determine if the assertions are valid or invalid. These assertions will only be valid if the other bridge components behave correctly.

An example is an assertion to ensure that validator signature is valid. If there’s a bug that returns an invalid signature or a malicious validator attaches an invalid signature, this assertion will be invalid. To handle this better, the Sommelier protocol team has made sure that error from an invalid validator signature won’t cause a panic that’ll stop the other processes depending on it. Another case is a bug causing the invalidation of the assertion between the Cosmos valset nonce and Ethereum valset nonce causing a panic which can lead to validator slashing. The Sommelier protocol team has successfully put a medium in place to handle all of these errors safely.

Assertions in the initialization phases or in the client code

This is the second category where panic causing statements can be invalidated. Assertions in the initialization phase of a process or in the client side can throw an invalid panic.

For instance, while trying to get balance of a Cosmos address, a panic can occur due to error connection errors. Since this code is in the client side, a panic can cause the halting of the orchestrator and may lead to a panic occurs a long time after the Orchestrator has been started.

Vacuously true assertions

Although this third category has little or no effects on validator slashing or halting of the Orchestrator, it tries to keep the codebase clean and easy to manage.

For instance Vacuously true assertions are guaranteed to be safe due to the code structure. Keeping them in the codebase makes it difficult to inspect codes as developers spend time on false positives. The Sommelier protocol team has successfully removed vacuously true assertions from the gravity bridge to make managing the bridge easy.

To learn more about Sommelier, please visit https://sommelier.finance/

To use Sommelier, try the Pairings App at https://app.sommelier.finance/

To participate in the community, please join the Telegram group https://t.me/getsomm.

To follow the project on Github, please star the project https://github.com/PeggyJV/sommelier.