refactor: transition from open_ethereum primatives (types/rlp) to Reth's Alloy (types/rlp) #1231

KolbyML · 2024-03-28T22:31:04Z

What was wrong?

open ethereum has been deprecated for 4 years
reth told us we should do this at Devconnect
sigp in the process of updating from open_ethereum primatives (types/rlp) to Reth's Alloy (types/rlp). Currently sigp/(enr/discv) are updated, but lighthouse is planning to upgrade as well.
Our current rlp code for era1 type transactions is broken, this PR will allow us to easily fix the the issue we have encoding typed transactions for era1 files

How was it fixed?

update all our code to use Reth alloy types and rlp instead of open ethereum's

why do we want this?

Open ethereum has been unmaintained for 4 years now. Switching to alloy (lighthouse is also planning to switch), will allow us to much more easily use libraries from Reth

A big reason is we can has a ton of crates we are going to want to use, this transition makes using Reth crates a billion percent easier.

morph-dev · 2024-04-02T08:10:05Z

In general, I like the idea and the initiative. However, I have some concerns.

There are several crates that are referencing your private repo, meaning they wouldn't get any updates / bug fixes. I checked few and they don't have only trivial changes.

Is there a plan for those crates to migrate to alloy as well, or do we plan to use alternative crates in the future? Would be good to know what are the next steps.

Maybe update the PR description with each such crate and plan for it for future.

KolbyML · 2024-04-02T08:32:08Z

In general, I like the idea and the initiative. However, I have some concerns.

There are several crates that are referencing your private repo, meaning they wouldn't get any updates / bug fixes. I checked few and they don't have only trivial changes.

The only one that doesn't have trivial changes is eth-trie.rs which we maintain. That is because it also required me to switch updated its RLP. The rest of the libraries mentioned are maintained by sigma prime and the changes are trival just changing openethereum_types to alloy-primative types

The libraries maintained by sigma prime are

ethereum_ssz
ethereum_serde_utils
tree_hash
ssz_types

I made PR's for all 4, it took less then an hour combined to convert all of them from ethereum-types to Reth's alloy types.

So yeah the only "private repo" with "don't have only trivial changes" is eth-trie.rs which we maintain. So I am assuming few means 1.

Is there a plan for those crates to migrate to alloy as well, or do we plan to use alternative crates in the future? Would be good to know what are the next steps.

To my knowledge sigp is going to upgrade sigp/(ethereum_ssz/ethereum_serde_utils/tree_hash/ssz_types) I made PR's for it. They already upgraded sig/(enr/discv5). sigp/(ethereum_ssz/ethereum_serde_utils/tree_hash/ssz_types) are very stable and aren't in active development either, so I think we are good in that regard.

I will reach out to sigp to get a more definitive answer, and update here on what I receive. I don't think the answer will be a blocker for this PR though.

ogenev

I have a few questions:

What is the motivation behind migrating from ethereum_types to alloy-primitives?

sigp in the process of updating from open_ethereum primatives (types/rlp) to Reth's Alloy (types/rlp). Currently sigp/(enr/discv) are updated, but lighthouse is planning to upgrade as well.

Could you link to PR/issue about that. What I found is this but they migrate only rlp to alloy-rlp.
Is it possible to migrate only the rlp crate and at a later stage to decide what to do with the primitive types?

KolbyML · 2024-04-02T16:54:49Z

I have a few questions:

What is the motivation behind migrating from ethereum_types to alloy-primitives?

Also so we can use the reth's REVM crate and json-rpc types seemlessly instead of a bunch of type conversion boilerplate.

sigp in the process of updating from open_ethereum primatives (types/rlp) to Reth's Alloy (types/rlp). Currently sigp/(enr/discv) are updated, but lighthouse is planning to upgrade as well.

Could you link to PR/issue about that. What I found is this but they migrate only rlp to alloy-rlp.

Discv5 doesn't use ethereum-types. I want to emphasize even if lighthouse aligns with this change or not that shouldn't impact the decision. We are an execution layer focused project and being able to use a lot of Reth's crates going forward will be a massive help. The 4 sigp libraries are very small, drops in a bucket compared to the REVM, even the json-rpc-types crate we want to use.

I asked and here is the response I got

So it looks like in a week or so after a team meeting we should get a definite answer.

Is it possible to migrate only the rlp crate and at a later stage to decide what to do with the primitive types?

Sigp's response referred to using "open-ethereum-types" as a bandaid in the image above
In the Image from Dragon from Reth he referred to it as a liability.

The truth being Parity hasn't in the Ethereum space for 4 years now. So I think it is clear we want to use Reth's primatives expessially with our growing interest in the REVM I see this as invaluable.

To answer the question directly

That would be very difficult and time consuming to accoplish. I believe that we are going to make the switch regardless. The writing has been on the wall for years. Open-ethereums (types/rlp) are stuck together like glue and Reth's alloy (types/rlp) are stuck together like glue It is very difficult and would be like 10 times more work for us to do one without the other.

ogenev · 2024-04-03T07:27:58Z

I agree that this is a good direction to go forward but I think the switch should be done more carefully.

This is a core change to our codebase and we should be more cautious relying on custom forks for core libraries like ethereum_ssz, tree_hash, ethereum_serde_utils, ssz_types and etc.

What problem are we trying to solve here? We want to fix an era1 decoding bug. Is this the simplest solution to this problem with the least friction? Is the alloy types migration at the top list of our priorities?

I would wait for sgp to update their crates before moving with this change and in the meantime, I'm more comfortable applying a quick fix for the era1 decoding issue.

morph-dev · 2024-04-03T08:08:53Z

I would say I'm with @ogenev on this one.

I noticed that alloy-primitives has features that might be useful for us and maybe eliminate need to have custom changes: ssz and maybe serde. Did you look into those?

Would it be possible to migrate in smaller chunks? Crate-by-crate would probably not work, but maybe structure-by-structure, i.e. each subnetwork separately.
It's definitely not ideal to depend on multiple crates that do the same thing, but I would say it's fine if it is just temporary thing (e.g. until Sigp migrates their crates).

Another related topic
Changes in eth_trie are not trivial, and crate itself wasn't really designed for our use case.
If we decide not to proceed with this PR, I can put an effort into creating and publishing the crate that will be more suited for us, that will use alloy types and we can migrate that part separately.

KolbyML · 2024-04-03T08:09:44Z

This is a core change to our codebase and we should be more cautious relying on custom forks for core libraries like ethereum_ssz, tree_hash, ethereum_serde_utils, ssz_types and etc.

Those libraries don't really change, they maybe add 1 thing every year or 6 months, and normally that is a new "feature" we don't need. The only change I made in those 4 libraries is cntr-alt-r open-ethereum types with reth's alloy types. This isn't the first time we have relied on custom forks well we are waiting for changes to be implemented on the main repo's. PR's are made on all the repos with the changes to reth's alloy types. On Thursday call if we want we can go over sigp's crates commit history to look at the changes. No meaningful changes have been made to those repos in years. ssz is simple serialization there isn't much to work on or change. I will take on the responsibility to work with sigp and maintain our forks for the forseeable future if required, till alloy is merged into them.

What problem are we trying to solve here? We want to fix an era1 decoding bug. Is this the simplest solution to this problem with the least friction? Is the alloy types migration at the top list of our priorities?

This is the simplest solution as the work is already done and tested

we want to use the revm in state
we want to use reth-rpc-types (with this change we won't need a ton of boiler plate as we get endpoints online)
Changing to this we can remove ethers-rs as a dependency as alloy replaces it as well
fixing the era1 rlp encoding/decoding issue

After we launch history I will be going to work on the state network assuming everything goes to plan. REVM uses reth's alloy types/rlp not open-ethereums. This PR is the setup to work with Reth's crates. A majority of their work is in modular crates and switching to their types allows us to easily taken advantage of them.

I would wait for sgp to update their crates before moving with this change and in the meantime, I'm more comfortable applying a quick fix for the era1 decoding issue.

This is the quick fix as the work is already done and tested. As stated above the sigp crates we rely on hardly change and when they do it is often a new "feature" we don't need. I am going to work with Sigp to resolve this for us, but I don't think this should block this PR.

TLDR
The work is already done. We want to switch because we want to use Reth's

REVM crate for the state network
json-rpc-types crate (without needing to write tons of boilerplate)
verkle is coming up, we will want to use the same crate as Reth (our state network/Reth's execution code) go hand and hand, we don't want to rewrite everything for open-ethereum's types

That is to name a few examples, but this PR opens doors beyond the examples I gave today, parity hasn't been in the ethereum ecosystem for 4 years, we are an execution aligned project, it makes sense to change to these types so we can reuse Reth's execution layer code.

I know this PR is "big", but it is unavoidable and this technical debt only grows overtime. The work is done.

KolbyML · 2024-04-03T08:12:18Z

Another related topic Changes in eth_trie are not trivial, and crate itself wasn't really designed for our use case. If we decide not to proceed with this PR, I can put an effort into creating and publishing the crate that will be more suited for us, that will use alloy types and we can migrate that part separately.

Are we not able to use this https://github.com/paradigmxyz/reth/tree/main/crates/trie ?

Reth has crates for all things execution layer, which is exactly why I think we should make this change. So we can reuse work already done instead of reinventing the wheel.

morph-dev · 2024-04-03T08:16:35Z

Are we not able to use this https://github.com/paradigmxyz/reth/tree/main/crates/trie ?

I wasn't aware of that crate, probably because it's not published. I will look into it today.

KolbyML · 2024-04-03T08:20:56Z

~~It looks like Alex Stokes is maintaining an ssz library using Reth's alloy-primitives https://github.com/ralexstokes/ssz-rs so maybe the move would be to switch to that~~

It seems not as optimized yet so I would prefer the forks

morph-dev · 2024-04-03T11:01:09Z

Are we not able to use this https://github.com/paradigmxyz/reth/tree/main/crates/trie ?

I wasn't aware of that crate, probably because it's not published. I will look into it today.

I looked into it, and we can likely use it. But, it's not really created for our use case and it comes with extra cost. Currently, and I'm not sure this will change any time soon, we only need to traverse certain path in a trie and verify that result is what it needs to be.

And also, I'm not sure if we want to use reth crates. I think revm might be enough for our use case (executing tx / block). The revm doesn't actually care about trie structure at all (at least to my understanding, it only needs a structure/db that will provide blocks, account info, code, and contract storage).

They all use alloy types, so transition would be useful anyway. All I'm saying is that we might not need to be so strongly integrated with reth.

njgheorghita

More of an initial pass-through. Mostly some comments and suggestions for using a different api. Imo, it cuts down the diff and improves readability if we're using the same api for the same functionality throughout the codebase. As to the status of this pr, we can discuss it during sync tm to see if we can reach consensus on how to handle it.

ethportal-api/src/types/consensus/beacon_block.rs

ethportal-api/src/types/consensus/beacon_state.rs

ethportal-api/src/types/consensus/body.rs

ethportal-api/src/types/consensus/execution_payload.rs

trin-history/src/validation.rs

ethportal-api/src/types/execution/block_body.rs

njgheorghita · 2024-04-03T15:44:25Z

ethportal-api/src/types/execution/block_body.rs

-}
-
-#[derive(Clone, Debug, PartialEq, Eq, Deserialize)]
+#[derive(Clone, Debug, PartialEq, Eq, Deserialize, RlpEncodable, RlpDecodable)]


I do remember that we needed to explicitly impl Encodable / Decodable here. Unfortunately, I can't remember exactly the reason why 😅 ... But this is another example of a change that seems like it makes sense, but unless it's explicitly covered in testing (and I don't immediately see any BlockBodyMerge tests down below) then it could lead to some rather tedious debugging down the road

This is changed in the era1 rlp fix PR

ethportal-api/src/types/execution/header.rs

ethportal-api/src/types/execution/transaction.rs

KolbyML · 2024-04-03T19:23:29Z

Another related topic Changes in eth_trie are not trivial,

The only "non-trivial" change is in 1 function decode_node() and that change is updating it from using open-ethereum/rlp to alloy/rlp. I want to clairfy this change isn't complex it is a library migration.

We can review the changes in this 1 function. I already tested the changes with our Portal-Hive state tests and the update to alloy/rlp passes all successfully.

. If we decide not to proceed with this PR, I can put an effort into creating and publishing the crate that will be more suited for us, that will use alloy types and we can migrate that part separately.

We are moving away from open-ethereum types and rlp regardless. So it isn't a question of not getting this PR in, it is how we are updating away from open-ethereum types/rlp. And I don't see a small function we can review and has been extensively tested as a blocker for this PR. This conversation is also not about this PR, this is just where the disucussions are starting.

I think writing a whole new merkle trie library is far more "non-trivial" then updating the rlp library eth-trie.rs uses and just reviewing it.

Another related topic Changes in eth_trie are not trivial,

I am very confused how 1 function changing from open-ethereum/rlp to alloy/rlp is a more complex change then writing a brand new library.

Verkle is coming in a year? no? Won't that make a merkle based state network obsolete? So why does a library not designed for our specific temporary usecase, but works for our specific usecase justify building a special solution.

My main point is I don't think this blocks this PR. And I am not sure why the complexity of the changes in eth-trie.rs are being overblown to justify building a brand new merkle trie library.

The changes in eth-trie.rs are not complex it is a library migration and the notable difference is 1 function which can be reviewed. It has already been tested and works with all our test data as well.

KolbyML · 2024-04-03T19:33:07Z

And also, I'm not sure if we want to use reth crates. I think revm might be enough for our use case (executing tx / block). The revm doesn't actually care about trie structure at all (at least to my understanding, it only needs a structure/db that will provide blocks, account info, code, and contract storage).

We already/will use

reth's json-rpc-types (We already use this for get_block_by_hash, but with a lot of type conversion helper functions, we plan to support all ethereum json-rpc calls so reusing this will be super helper, changing to alloy means removing the boiler plate to use these types)
We use there rpc server crate (this doesn't rely on alloy tmk, but it is a reth crate)
we will want to use the same verkle crate when that is made no?
revm

If we don't want to use the trie crate that is fine, but deciding not to use 1 reth crate doesn't mean we don't get value from other reth crates or we won't use them.

They all use alloy types, so transition would be useful anyway. All I'm saying is that we might not need to be so strongly integrated with reth.

Reth is modular. I am not sure how using a crate is the same thing as All I'm saying is that we might not need to be so strongly integrated with reth sentiment. The main sentiment here is to not use parity's libraries as they haven't been in the ethereum ecosystem for 4 years. That is a clear libility. Reth is actively maintaining types/rlp we can change to. Being able to reuse some code is just icing on the cake, all be it some tasty icing.

Crates are just tools, Reth just happens to build a lot of tools. If there is a tool we can use to get something done faster I see that as a win. We don't want to rebuild everything from scratch unless there is a reason for it.

Portal is a mainly execution layer aligned project. So it makes sense an ethereum execution layer client (Reth) with a modular design would build a lot of tools we can use

…h's Alloy (types/rlp)

KolbyML · 2024-04-04T00:39:34Z

I implemented the era1 change using open-ethereum/rlp
#1237
There is more information in the PR, but in short it is 3.64 times slower in an encode/decode test of an era1 file compared to using reth's alloy/rlp. It also uses a lot more peak memory usage.

I don't think it makes sense to use open-ethereum rlp, for all the reasons above. 3.64 times slower is no joke.

njgheorghita · 2024-04-04T13:33:21Z

ethportal-api/src/types/execution/block_body.rs

@@ -248,19 +211,23 @@ impl ssz::Decode for BlockBodyLegacy {
        let uncles: Vec<u8> = decoder.decode_next()?;
        let txs: Vec<Transaction> = txs
            .iter()
-            .map(|bytes| rlp::decode(bytes))
+            .map(|bytes| Decodable::decode(&mut bytes.as_slice()))


Well, personally I'd like to see alloy_rlp::decode() here, but that doesn't seem to be an available method, which is an odd api choice imo....

ethportal-api/src/types/execution/block_body.rs

njgheorghita · 2024-04-04T13:39:23Z

ethportal-api/src/types/execution/block_body.rs

@@ -475,15 +393,15 @@ mod tests {
    #[case(TX6, 41942)]
    fn encode_and_decode_txs(#[case] tx: &str, #[case] expected_nonce: u32) {
        let tx_rlp = hex_decode(tx).unwrap();
-        let tx = rlp::decode(&tx_rlp).expect("error decoding tx");
+        let tx = Transaction::decode(&mut tx_rlp.as_slice()).expect("error decoding tx");


I'd prefer Decodable over Transaction here

njgheorghita · 2024-04-04T13:39:41Z

ethportal-api/src/types/execution/block_body.rs

-            rlp::decode(&hex_decode(TX17).unwrap()).unwrap(),
-            rlp::decode(&hex_decode(TX18).unwrap()).unwrap(),
-            rlp::decode(&hex_decode(TX19).unwrap()).unwrap(),
+            Transaction::decode(&mut hex_decode(TX1).unwrap().as_slice()).unwrap(),


Decodable > Transaction

njgheorghita · 2024-04-04T13:42:18Z

ethportal-api/src/types/execution/header.rs

-        } else {
-            s.begin_list(stream_length_without_seal);
+impl Encodable for Header {
+    fn encode(&self, out: &mut dyn bytes::BufMut) {


I'm not sure we want to get rid of the with_seal bool, why was it removed?

It wasn't used

njgheorghita · 2024-04-04T13:57:02Z

ethportal-api/src/types/execution/receipts.rs

-                Receipt::decode(&hex_decode(RECEIPT_16).unwrap()).unwrap(),
-                Receipt::decode(&hex_decode(RECEIPT_17).unwrap()).unwrap(),
-                Receipt::decode(&hex_decode(RECEIPT_18).unwrap()).unwrap(),
+                Receipt::decode(&mut hex_decode(RECEIPT_0).unwrap().as_slice()).unwrap(),


Decodable > Receipt in the following 2 lists, and for all the following uses of Receipt::decode() in these tests

njgheorghita · 2024-04-04T13:58:50Z

ethportal-api/src/types/execution/transaction.rs

-use rlp_derive::{RlpDecodable, RlpEncodable};
+use alloy_primitives::{keccak256, Address, B256, U256, U64};
+use alloy_rlp::{
+    length_of_length, Decodable, Encodable, Error as RlpError, Header, RlpDecodable, RlpEncodable,


Header as RlpHeader

njgheorghita · 2024-04-04T13:59:16Z

ethportal-api/src/types/execution/transaction.rs

-        keccak_hash::keccak(rlp::encode(self))
+    pub fn hash(&self) -> B256 {
+        let mut buf = vec![];
+        self.encode(&mut buf);


alloy_rlp::encode()

njgheorghita · 2024-04-04T13:59:54Z

ethportal-api/src/types/execution/transaction.rs

-    fn rlp_append(&self, s: &mut RlpStream) {
+    fn encode(&self, out: &mut dyn bytes::BufMut) {
+        // we don't wrap versioned transactions with a string header
+        let with_header = false;


then why do we have an if with_header {} clause later? with_header will never evaluate to true

We use it in the era 1 fix PR #1231 (comment)

njgheorghita · 2024-04-04T14:03:07Z

ethportal-api/src/types/execution/transaction.rs

+    fn decode(buf: &mut &[u8]) -> alloy_rlp::Result<Self> {
+        if let Some(&first) = buf.first() {
+            if first == EMPTY_STRING_CODE {
+                buf.advance(1);


Why are we advancing the buf here? I'm just not sure that there's a test for this code path, or did you find one and this was required to get it passing?

I thought it was cleaner then doing &mut &buf[1..]

I think it is less error prone as well

ogenev

Ok let's give this a go, main main comment is that I would like to see alloy-primitives version updated to the latest minor 0.7.0 on all crates and see some tests for u256_from_dec_str.rs. ⛵

ogenev · 2024-04-05T06:54:04Z

Cargo.toml

@@ -13,12 +13,13 @@ categories = ["cryptography::cryptocurrencies"]
 description = "A Rust implementation of the Ethereum Portal Network"

 [dependencies]
+alloy-primitives = "0.6.4"


There is a new latest 0.7.0 version, let's update it in this repo, and all forked repos.

ogenev · 2024-04-05T07:09:17Z

Cargo.toml

@@ -41,7 +41,7 @@ tempfile = "3.3.0"
 tokio = { version = "1.14.0", features = ["full"] }
 tracing = "0.1.36"
 tracing-subscriber = "0.3.15"
-tree_hash = "0.5.2"
+tree_hash = { git = "https://github.com/KolbyML/tree_hash.git", rev = "c402373ce2b430551eb8debd85512ceac9567210" }


I will comment on the tree_hash fork code here.

On line 122, I think it is more efficient if we do the following:

let mut result = [0; HASHSIZE]; result.copy_from_slice(self.as_le_slice());

instead of:

let mut result = [0; HASHSIZE]; for (index, i) in self.as_le_slice().iter().enumerate() { result[index] = i.clone(); }

ogenev · 2024-04-05T07:15:04Z

ethportal-api/Cargo.toml

-ethereum_ssz_derive = "0.5.3"
+discv5 = { version = "0.4.1", features = ["serde"] }
+eth_trie = { git = "https://github.com/kolbyml/eth-trie.rs.git", rev = "a09b2365f1457cb83bae5ebfa2cf133a9dd1657f" }
+ethereum_serde_utils = { git = "https://github.com/KolbyML/ethereum_serde_utils.git", rev = "25b69f5dbd3ac871217ad24fc42304a93000d8da" }


I see that you added a new file u256_from_dec_str.rs in the ethereum_serde_utils fork. I would like to see some tests added for this functionality before depending on it.

ogenev · 2024-04-05T07:20:07Z

ethportal-api/Cargo.toml

@@ -29,23 +30,21 @@ lazy_static = "1.4.0"
 nanotemplate = "0.3.0"
 quickcheck = "1.0.3"
 rand = "0.8.5"
-reth-rpc-types = { tag = "v0.1.0-alpha.10", git = "https://github.com/paradigmxyz/reth.git"}
+reth-rpc-types = { tag = "v0.2.0-beta.4", git = "https://github.com/paradigmxyz/reth.git"}


Did reth switch to beta.5? Let's update it here too.

Reth bumped the alloy version after the release of beta.5 so I updated it to the commit for the bump commit

KolbyML self-assigned this Mar 28, 2024

KolbyML force-pushed the update-to-alloy-rlp branch 6 times, most recently from 3788a50 to 0f1631c Compare April 1, 2024 07:29

KolbyML changed the title ~~feat: transition from rlp -> alloy-rlp~~ feat: transition from open_ethereum primatives (types/rlp) to Reth's Alloy (types/rlp) Apr 1, 2024

KolbyML force-pushed the update-to-alloy-rlp branch 2 times, most recently from cb9783f to e011600 Compare April 1, 2024 08:20

KolbyML marked this pull request as ready for review April 1, 2024 08:32

KolbyML requested review from mrferris, njgheorghita, ogenev and morph-dev April 1, 2024 08:33

KolbyML changed the title ~~feat: transition from open_ethereum primatives (types/rlp) to Reth's Alloy (types/rlp)~~ refactor: transition from open_ethereum primatives (types/rlp) to Reth's Alloy (types/rlp) Apr 1, 2024

KolbyML force-pushed the update-to-alloy-rlp branch 2 times, most recently from 3ff205d to dd830d4 Compare April 1, 2024 16:05

KolbyML mentioned this pull request Apr 1, 2024

fix: era1 typed-(transaction/receipt) encode/decode #1234

Merged

ogenev requested changes Apr 2, 2024

View reviewed changes

KolbyML requested a review from ogenev April 2, 2024 16:55

njgheorghita reviewed Apr 3, 2024

View reviewed changes

refactor: transition from open_ethereum primatives (types/rlp) to Ret…

9be8ba8

…h's Alloy (types/rlp)

KolbyML force-pushed the update-to-alloy-rlp branch from dd830d4 to 9a23c94 Compare April 3, 2024 21:45

fix: resolve pr concerns

5f0c00c

KolbyML force-pushed the update-to-alloy-rlp branch from 9a23c94 to 5f0c00c Compare April 3, 2024 21:50

KolbyML requested a review from njgheorghita April 3, 2024 21:55

njgheorghita reviewed Apr 4, 2024

View reviewed changes

fix: pr concerns

52f5f0e

KolbyML requested a review from njgheorghita April 4, 2024 14:52

njgheorghita approved these changes Apr 4, 2024

View reviewed changes

ogenev approved these changes Apr 5, 2024

View reviewed changes

fix: pr concerns

6c58cc7

KolbyML merged commit 47f8805 into ethereum:master Apr 5, 2024
11 checks passed

KolbyML mentioned this pull request Jan 17, 2025

Fix encode TalkRequest regression during library transition sigp/discv5#276

Merged

3 tasks

KolbyML deleted the update-to-alloy-rlp branch January 22, 2025 07:52

refactor: transition from open_ethereum primatives (types/rlp) to Reth's Alloy (types/rlp) #1231

refactor: transition from open_ethereum primatives (types/rlp) to Reth's Alloy (types/rlp) #1231

Conversation

KolbyML commented Mar 28, 2024 • edited Loading

What was wrong?

How was it fixed?

why do we want this?

morph-dev commented Apr 2, 2024 • edited Loading

KolbyML commented Apr 2, 2024 • edited Loading

ogenev left a comment

Choose a reason for hiding this comment

KolbyML commented Apr 2, 2024 • edited Loading

ogenev commented Apr 3, 2024 • edited Loading

morph-dev commented Apr 3, 2024 • edited Loading

KolbyML commented Apr 3, 2024

KolbyML commented Apr 3, 2024

morph-dev commented Apr 3, 2024

KolbyML commented Apr 3, 2024 • edited Loading

morph-dev commented Apr 3, 2024

njgheorghita left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KolbyML commented Apr 3, 2024 • edited Loading

KolbyML commented Apr 3, 2024 • edited Loading

KolbyML commented Apr 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ogenev left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ogenev Apr 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KolbyML commented Mar 28, 2024 •

edited

Loading

morph-dev commented Apr 2, 2024 •

edited

Loading

KolbyML commented Apr 2, 2024 •

edited

Loading

KolbyML commented Apr 2, 2024 •

edited

Loading

ogenev commented Apr 3, 2024 •

edited

Loading

morph-dev commented Apr 3, 2024 •

edited

Loading

KolbyML commented Apr 3, 2024 •

edited

Loading

KolbyML commented Apr 3, 2024 •

edited

Loading

KolbyML commented Apr 3, 2024 •

edited

Loading

KolbyML commented Apr 4, 2024 •

edited

Loading

ogenev left a comment •

edited

Loading

ogenev Apr 5, 2024 •

edited

Loading