This document discusses cross-chain communication between StarkNet and Ethereum. It provides an overview of how messaging works currently from L2 to L1 by submitting transactions to StarkNet that initialize syscalls to send messages to Ethereum contracts. It also discusses how messaging could work from L1 to L2 by having Ethereum contracts initiate messages that get handled by corresponding functions on StarkNet contracts. The document explains that this allows blockchains to communicate natively with mathematical proof and without trust assumptions, and suggests this could be used to design custom bridging protocols and provide tight integration between L1 and L2.

1. Bridging with StarkNet
February 2022
1
StarkNet edu team
https://github.com/starknet-edu | @starkwareltd

2. Cross Chain Communication
2
@starkwareltd
● Today used for bridging assets:
○ Tokens/NFTs L1 <> L2
○ Tokens/NFTs L1 <> L1

3. Cross Chain Communication
3
● Tomorrow can we build more bridges?
○ Bridge permissions?
○ Bridge computation?
○ Bridge instructions?
@starkwareltd

4. Cross Chain Communication
4
● Can we build less bridges?
○ Let users pass data instead of assets
○ Let developers build their own bridges
@starkwareltd

5. Talking to Ethereum

6. L2 -> L1 Messaging
Status Description
Submit Tx L2 Client sends TX
‘send_message_to_
l1’
TX initializes L2 Contract syscall to send
message to L1 Contract
Proof L2 TX including message included in Proof
and verified on L1
State Update Message attached to state update, Core
Contract increases counter, and
‘LogMessageToL1’ event emit
Message Cleared L1 Recipient Contract can consume message
in L1 TX via ‘consumeMessageFromL2’. Upon
valid msg params counter decrement and
message considered handled

7. 1. Submit Tx
7
@starkwareltd

8. 2. send_message_to_l1
8
● Message is an array of felts, to a Recipient
● Recipient is a L1 account
@starkwareltd

9. 3. Message registered
9
● Message registered by StarkNet OS
● Message indexed by it’s hash
@starkwareltd

10. Withdrawal Call Flow
10
@starkwareltd

11. 4. Message received on L1
11
● StarkNet’s state is updated on Ethereum all ‘sent’
messages are updated as ‘pending’
● Core Contracts increment message counter
● All message data can be retrieved for later use
@starkwareltd

12. 4. Message consumed
12
● Recipient should be calling StarkNet contract directly, but
trigger can be arbitrary
● Counter decremented by 1
● Full payload needs to be sent as calldata
@starkwareltd

13. Delays
13
● Messages are transmitted with proofs
● Proof verification frequency is currently every 2h on testnet
● This means your L2 -> L1 messages will be slow to debug!
● As usage of StarkNet picks up, this frequency may lower
@starkwareltd

14. Talking to StarkNet

15. L1 -> L2 Messaging
Status Description
‘sendMessageL2’ L1 Contract initiates a message w/
destination address. Core Contract
hashes msg params + increases counter
‘l1_handler’ L2 Contract’s corresponding message
handler is invoked
Proof Handled message attached to proof of
relevant state update
State Update Message Consumption by L2 Contract
included in State Update
Message Cleared Initial counter is decrement and message
considered handled

16. 1. sendMessageL2
16
● Call the `sendMessageToL2` selector on the CCs
● Message is indexed and counter is incremented
● Specify the L2 recipient, as well as the function selector to
call
@starkwareltd

17. 2. l1_handler
17
● After 10 block confs, your message is confed on StarkNet
● StarkNet initiates the corresponding L2 tx defined by the
contracts ‘l1_handler’
@starkwareltd

18. 3. Prove it
18
● The execution that takes place in the ‘l1_handler’ is
added to the proof written back to L1
@starkwareltd

19. 4. State Update
19
● The state is updated with the included ‘l1_handler’
execution
@starkwareltd

20. 5. Message cleared
20
● Message is now cleared from the Core Contracts
storage
● Message is considered handled
@starkwareltd

21. Why this is cool

22. Blockchains talking natively
22
● No element of trust in the mechanism
● Ethereum has certainty of what happened on StarkNet
● Ethereum has mathematical proof that a message was sent
@starkwareltd

23. Design your own protocol
23
● No assumption about the payload sent (i.e. ‘payload_size=X’)
● Smart contracts on both sides can act upon data sent by L2 to move assets
● Assets can sit on any smart contract using the bridge
○ Tired of liquidity waiting in a bridge?
○ Design a bridge that has liquidity sitting on AAVE
○ Afraid of the security?
○ Implement a time lock on your bridge and select your own security
@starkwareltd

24. Tight L1 integration
24
● Full remote control: Send to a L1/L2 contract instructions for an arbitrary call
○ Recipient
○ Function selector
● L1 liquidity is StarkNet liquidity
○ You can use directly L1 assets in your applications
@starkwareltd

25. Mooorrr Resoruces
Docs:
https://docs.starknet.io/documentation/develop/L1-L2_Communication
Exercise:
https://github.com/starknet-edu/starknet-messaging-bridge
Message Viewer:
https://starkscan.co/messagelogs

26. Thanks!
January 2022
26
@starkwareltd
StarkNet edu team