[PoC] Message Queue contract by olegrok · Pull Request #789 · NilFoundation/nil

olegrok · 2025-04-10T11:25:40Z

⚠️ Note: This patch is not intended to be merged as-is. It serves only as a demonstration of how a Message Queue contract could be implemented.

There are several issues that arise with this approach, and not all of them have been resolved yet.

Summary of Changes

A Message Queue contract is deployed on each shard.
The contract currently provides only basic functionality:
- Adding messages to the queue.
- Clearing the queue.
Queue clearing is performed at the beginning of each block via a system call sent by proposer.
The most interesting part is message persistence: both the message data and the sender’s address are saved.
Only SmartAccount.send method is ported to this approach.
At the end of the block production cycle, all messages from the queue are collected and included in the "out transaction tree".
- In the future, we might completely remove the transaction tree.
- For now, with both approaches coexisting, this hybrid implementation is used.
Malformed or invalid messages are currently dropped silently.

Potential Next Steps

Reduce and consolidate existing message-sending interfaces.
Replace the Nil.sendTransaction interface with MessageQueue.sendRawTransaction.
Improve error handling and diagnostics.
...

shermike · 2025-04-10T13:22:24Z

nil/internal/execution/block_generator.go

 		g.executionState.AppendForwardTransaction(txn)
 	}

+	messages, err := GetMessageQueueContent(g.executionState)


Shouldn't we get messages queue from other shards targeting to our shard?

We should do that by proposer. I suggest to implement step-by-step solution. It's the first step in this directon.

Right now an approach doesn't break existing code. We just copy a message queue content to an existing outbound messages tree. Ideally, we need to drop old approach and then it will be possible to use only queue account state.

shermike · 2025-04-10T13:24:24Z

nil/contracts/solidity/system/MessageQueue.sol

+        delete queue;
+    }
+
+    Message[] private queue;


Maybe it is worth to separate this array by shard. So the other shard can fetch only messages addressed to him: getMessages(uint shardId)

Right now we don't have a special interface to send data to specific shard. Our smart accounts operates with raw calldata and we can extract destination shard only after decoding a message. But we don't have a SSZ decoder in Solidity. So here we have single queue for all messages. In future then we will pass destination shards/address explicitly it will be possible.

What are the limits on the size of the queue or message size in queue?

Also how would this compare to another approach such as emitting an event instead?

What are the limits on the size of the queue or message size in queue?

Right now there is no any limits but we can add them

Also how would this compare to another approach such as emitting an event instead?

I didn't think about emitting events but this looks like an attempt to move all magic out of EVM. Sounds interesting but I'm not sure it's what we expect. Should be discussed. Thanks for idea.

Gezort · 2025-04-11T14:36:28Z

nil/contracts/solidity/system/MessageQueue.sol

+    bytes data;
+    address sender;


it may be convenient to introduce more fields here (e.g. tokens)

In the first version I'd just want to check that it will work at all. basic test passed. We can discussed it and extends current implementation.

idea404 · 2025-04-11T14:17:52Z

nil/internal/collate/proposer.go

+	if err != nil {
+		return fmt.Errorf("failed to create MQ prune transaction: %w", err)
+	}
+	p.proposal.SpecialTxns = append(p.proposal.SpecialTxns, txn)


What happens if the tx fails or if the block containing the tx is not finalized?

If such TX fail we fail block validation on consensus and then new block in the next round will be suggested.

idea404 · 2025-04-11T14:21:34Z

nil/contracts/solidity/system/MessageQueue.sol

+        delete queue;
+    }
+
+    Message[] private queue;


What are the limits on the size of the queue or message size in queue?

idea404 · 2025-04-11T14:36:03Z

nil/contracts/solidity/system/MessageQueue.sol

+        delete queue;
+    }
+
+    Message[] private queue;


Also how would this compare to another approach such as emitting an event instead?

idea404 · 2025-04-11T15:05:19Z

nil/contracts/solidity/system/MessageQueue.sol

+}
+
+contract MessageQueue is IMessageQueue{
+    function sendRawTransaction(bytes calldata _message) external override {


What are thoughts around supporting attaching value?

Value is attached inside this message. It's out InternalTransactionPayload encoded with SSZ.
We can try to send messages encoded in EVM serialization but it's also should be discussed.

Do we need to send SSZ inside EVM at all. Or should be accept only ABI packed data and only then we need to repack into SSZ

olegrok added 4 commits April 10, 2025 14:40

add message queue contract

a31c70b

WIP2

d688e35

WIP3

da36cd5

WIP

41f9496

olegrok requested review from avm, knazarov and shermike April 10, 2025 11:25

olegrok temporarily deployed to prod April 10, 2025 11:25 — with GitHub Actions Inactive

shermike reviewed Apr 10, 2025

View reviewed changes

Gezort reviewed Apr 11, 2025

View reviewed changes

idea404 reviewed Apr 11, 2025

View reviewed changes

Conversation

olegrok commented Apr 10, 2025

Summary of Changes

Potential Next Steps

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants