Rust x Ethereum Day 2023 at The Foundry SF

Isaac Patka presents on "Transaction middleware and policy language"

I'm Isaac, and I'll be talking about how we can design various languages for how we route transactions on the node level in a modular way.

So we've seen a few examples of how we can add modules as extensions to Reith today, whether that's builders, MEV protection, all sorts of bundlers.

But what I'm primarily talking about here is we're talking about when transactions are broadcast before mempool.

What are the things that we can do about that transaction and how can we route it?

For example, you can think of how we would add various security features to a transaction broadcasting system based on the context of that transaction and decide to not only just pass through transactions to be broadcast, but in some cases, block, send things for MFA, perhaps even create various complex MPC systems based on transaction context.

So in order to do this in a modular way, which is customizable, we don't want to have to code absolutely all of our security rules for these modules.

In Rust, sometimes we want to have modular rule sets or policy statements so that we can make decisions on what transactions do.

So we started building a just various like JSON policy documents for instructing these modules on how to route transactions and what to do, And then after making the first version, I wanted to look out into the space to see is there something that already exists here?

Because these are not entirely new problems that we're solving around making decisioning based on context.

So I found a really cool Rust-based language written by AWS called Cedar.

This is a language which I'm pretty sure powers a lot of how IAM handles resourcing and accessing things.

It was not built for crypto applications.

And so the main applications in their docs look like you're building Instagram or something, where it's like you're trying to permission users from interacting with photo albums based on who they're friends with.

But there are some core concepts here which are very useful.

We're still talking about people trying to interact with resources given certain contexts.

So how can we make a language like this understand crypto contexts?

So we integrated Cedar with EthersRS with a to do to integrate Alloy and make it so that we can help this policy engine, this general purpose like routing and policy decisioning tool, understand the context of transactions and decide when transactions should be broadcast, when they should be broadcast via alternative means, and when they should be perhaps blocked or sent for additional confirmation.

So we can also add additional hooks and Decorators here to tell it what to do with transactions so we can say when there's certain transactions that are coming from Wallets that are eo a transactions contract transactions when they have certain contexts around value or ABI What do we do with them So we want to trigger web hooks, we want to send things to maybe private broadcasting pools.

All of that we can do in this like just declarative language.

So we need a few things to make this work.

So this is a little snippet of an extension I wrote to add U256 context support to the Cedar policy engine.

We need to do similar things like that for ABI and transaction decoding.

And we also need the schemas, So we need the policy engine to understand what the map of the space looks like for contracts.

So we need to understand how EOAs interact with contracts, how they interact with them through transactions, describe the concept of networks.

And by building up all of this information about actions and schemas and policies, we can automate a lot of the routing for transactions at the node layer.

So the cool thing about this, that some vision I have for how these nodes can become a lot smarter than these pass-through broadcasting layers, is that nodes can understand the context of what transactions are trying to do and help people make decisions on where they should go.

So I think there's a lot of automation that we can build into the core node layer by combining things like perhaps a DSL4 policy with the bundling modules we saw earlier today, the MEV modules we saw earlier today.


Speaker 0: Hello, everyone. I'm Isaac, and I'll be talking about how we can design various languages for how we route transactions on the node level in a modular way. So we've seen a few examples of how we can add modules as extensions to Reith today, whether that's builders, MEV protection, all sorts of bundlers. But what I'm primarily talking about here is we're talking about when transactions are broadcast before mempool. What are the things that we can do about that transaction and how can we route it?

For example, you can think of how we would add various security features to a transaction broadcasting system based on the context of that transaction and decide to not only just pass through transactions to be broadcast, but in some cases, block, send things for MFA, perhaps even create various complex MPC systems based on transaction context. So in order to do this in a modular way, which is customizable, we don't want to have to code absolutely all of our security rules for these modules. In Rust, sometimes we want to have modular rule sets or policy statements so that we can make decisions on what transactions do. So we started building a just various like JSON policy documents for instructing these modules on how to route transactions and what to do, And then after making the first version, I wanted to look out into the space to see is there something that already exists here? Because these are not entirely new problems that we're solving around making decisioning based on context.

So I found a really cool Rust-based language written by AWS called Cedar. This is a language which I'm pretty sure powers a lot of how IAM handles resourcing and accessing things. It was not built for crypto applications. And so the main applications in their docs look like you're building Instagram or something, where it's like you're trying to permission users from interacting with photo albums based on who they're friends with. But there are some core concepts here which are very useful.

We're still talking about people trying to interact with resources given certain contexts. So how can we make a language like this understand crypto contexts? So we integrated Cedar with EthersRS with a to do to integrate Alloy and make it so that we can help this policy engine, this general purpose like routing and policy decisioning tool, understand the context of transactions and decide when transactions should be broadcast, when they should be broadcast via alternative means, and when they should be perhaps blocked or sent for additional confirmation. So we can also add additional hooks and Decorators here to tell it what to do with transactions so we can say when there's certain transactions that are coming from Wallets that are eo a transactions contract transactions when they have certain contexts around value or ABI What do we do with them So we want to trigger web hooks, we want to send things to maybe private broadcasting pools. All of that we can do in this like just declarative language.

So we need a few things to make this work. We need some extensions for data types. So this is a little snippet of an extension I wrote to add U256 context support to the Cedar policy engine. We need to do similar things like that for ABI and transaction decoding. And we also need the schemas, So we need the policy engine to understand what the map of the space looks like for contracts.

So we need to understand how EOAs interact with contracts, how they interact with them through transactions, describe the concept of networks. And by building up all of this information about actions and schemas and policies, we can automate a lot of the routing for transactions at the node layer. So the cool thing about this, that some vision I have for how these nodes can become a lot smarter than these pass-through broadcasting layers, is that nodes can understand the context of what transactions are trying to do and help people make decisions on where they should go. So I think there's a lot of automation that we can build into the core node layer by combining things like perhaps a DSL4 policy with the bundling modules we saw earlier today, the MEV modules we saw earlier today. So, thank you.

See all Paradigm transcripts on Youtube

Rust x Ethereum Day - Transaction middleware and policy language