Optimize RLP serialization #765

chirag-parmar · 2024-12-11T10:08:15Z

Description

This PR improves upon the memory and time complexity of the RLP serialisation algorithm(RlpWriter). The existing implementation of RLP uses the RlpWriter that extends a buffer and moves memory whenever required. This wastes a lot of time for large payloads. This PR, firstly, implements a RlpLengthTracker that dry runs the serialisation to calculate the full length of the serialised data and the prefixes of lists. Secondly, the RlpTwoPassWriter uses the pre-calculated values to assign memory in one shot and avoid moving memory to make space for prefixes.

Additionally, the PR also implements a RlpHashWriter that directly updates the sponge construction of keccak256 hash to avoid allocating any memory (few exceptions which are negligible).

Rationale

Naive implementations of RLP serialisation require moving memory because prefixes of lists can only be calculated after serialising the items within the list. Since complex types such as objects are represented as lists the serialisation of any data structure in Ethereum requires moving the encoded/serialised list items to make space for the prefix. In cases where the encoded buffer is hashed, the encoded list items cannot be absorbed until the prefix is calculated.

However, the encoded lengths of base types can be calculated without actually serialising them (or allocating memory). This is exploited to split the computation into two. First to calculate lengths of the base types, and then to actually serialise the data.

By calculating the lengths of the base types we can find the length of encoded list items and thereby also the length of the prefix (without actually serialising the prefix). Additionally, we also derive the total length of the serialised data from this. This logic is implemented as the RlpLengthTracker which records listLengths, prefixLengths and the totalLength.

In the second part of the computation, we actually serialise the data (and the prefixes) without skipping over memory or moving memory positions. This is implemented as the RlpTwoPassWriter, "two-pass" because we iterate through the data twice. Because the data is iterated through twice the RlpTwoPassWriter can only be used within the encode function. In cases where users manually call append, the RlpTwoPaasWriter would require users to manually run the RlpLengthTracker for the first pass and then the second pass.

RlpHashWriter also uses two passes but for the second pass it absorbs the data directly into the sponge construction of keccak instead of allocating memory thereby saving memory (amortized constant usage). And for similar reasons as stated above, a new api method, encodeHash is exposed.

Changelog

introduces a new method encodeHash for constant memory RLP encoding and hashing.
updates the encode method to serialise data in "two passes".
isolates all writer implementations into individual files with writer.nim handling only the dependency injection architecture of the append method
introduces two new tests, test_hashes.nim and test_rlp_profiler.nim. The first, does a sanity check of the hash writer. The second one, time profiles the new writer implementation to the default implementation.

Benchmarks

using --mm=refc (refc GC)

CPU Time [Transaction serialization using two pass writer] 0.000001402s
CPU Time [Block Sequence serialization using two pass writer] 0.000002592s
CPU Time [Block serialization using two pass writer] 0.000007493s
.CPU Time [Transaction serialization using default writer] 0.000001559s
CPU Time [Block Sequence serailization using default writer] 0.000003281s
CPU Time [Block serialization using default writer] 0.000009589s
.CPU Time [Transaction hashing using hash writer] 0.000001810s
CPU Time [Block Sequence hashing using hash writer] 0.000006301s
CPU Time [Block hashing using hash writer] 0.000028100s
.CPU Time [Transaction hashing using default writer and then hash] 0.000002291s
CPU Time [Block Sequence hashing using default writer and then hash] 0.000007532s
CPU Time [Block hashing using defualt writer and the hash] 0.000007491s

using --mm=orc (orc GC)

CPU Time [Transaction serialization using two pass writer] 0.000000901s
CPU Time [Block Sequence serialization using two pass writer] 0.000002089s
CPU Time [Block serialization using two pass writer] 0.000005357s
.CPU Time [Transaction serialization using default writer] 0.000000973s
CPU Time [Block Sequence serailization using default writer] 0.000002513s
CPU Time [Block serialization using default writer] 0.000006726s
.CPU Time [Transaction hashing using hash writer] 0.000001609s
CPU Time [Block Sequence hashing using hash writer] 0.000006161s
CPU Time [Block hashing using hash writer] 0.000026231s
.CPU Time [Transaction hashing using default writer and then hash] 0.000001879s
CPU Time [Block Sequence hashing using default writer and then hash] 0.000006502s
CPU Time [Block hashing using defualt writer and the hash] 0.000006492s

eth/rlp/default_writer.nim

eth/rlp/hash_writer.nim

eth/rlp/two_pass_writer.nim

eth/rlp/writer.nim

eth/rlp/hash_writer.nim

eth/rlp/two_pass_writer.nim

jangko · 2025-01-07T07:19:23Z

eth/rlp/writer.nim

+  when nestedListsDepth > 0:
+    var tracker = StaticRlpLengthTracker[nestedListsDepth]()
+  elif nestedListsDepth == 0:
+    var tracker = DynamicRlpLengthTracker()


What kind of types need DynamicLengthTracker? a string/int? Can we use StaticRlpLengthTracker[1]()?

Types that are recursive and only fully defined during runtime. By a full definition I mean, these types assume the full structure of the object they hold only at runtime. At compile time they are empty. For example, JsonNode

references too

jangko · 2025-01-07T08:09:17Z

I'm curious why block hashing using hash writer is slower than default writer + hash. And can you add block header hashing measurement too? Because in nimbus-eth1 we only use transaction hashing and block header hashing only. Almost no need to hash a full block.

chirag-parmar · 2025-01-07T08:25:36Z

I'm curious why block hashing using hash writer is slower than default writer + hash.

I have been wondering the same thing for almost two weeks now. I made a lot of measurements using the time profiler on MacOS Instruments but couldn't corner it down. Then yesterday, I switched the tests, i.e. I ran the default writer + hash benchmark first and then the hash writer. This time hash writer was faster in the same order of magnitude. I think it has something to do with caching or garbage collection, I'm not sure though but I'm trying to corner this down.

what is weird is that, the benchmark is calculated by collecting 100 measurements and then averaging them out. So caching shouldn't be an issue. Additionally, the encoding benchmarks before hashing benchmarks use the same data which means it should already be cached

And can you add block header hashing measurement too? Because in nimbus-eth1 we only use transaction hashing and block header hashing only. Almost no need to hash a full block.

Yes, will add this

jangko · 2025-01-07T08:42:14Z

Nim generic instantiation cache(in the compiler) is known to have a bug. And by looking into the bug tracker, I believe it still there.
https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aopen+generic+cache
This is only a hunch. The exact problem is yet to be found.

chirag-parmar · 2025-01-07T10:34:08Z

refc GC

CPU Time [Transaction serialization using two pass writer] 0.000001261s
CPU Time [Block Sequence serialization using two pass writer] 0.000002928s
CPU Time [Block serialization using two pass writer] 0.000006690s
CPU Time [Block header serialization using two pass writer] 0.000000858s

CPU Time [Transaction serialization using default writer] 0.000001452s
CPU Time [Block Sequence serailization using default writer] 0.000003362s
CPU Time [Block serialization using default writer] 0.000009260s
CPU Time [Block header serialization using default writer] 0.000001547s

CPU Time [Transaction hashing using hash writer] 0.000001419s
CPU Time [Block Sequence hashing using hash writer] 0.000006039s
CPU Time [Block hashing using hash writer] 0.000027683s
CPU Time [Block header hashing using hash writer] 0.000004401s

CPU Time [Transaction hashing using default writer and then hash] 0.000002267s
CPU Time [Block Sequence hashing using default writer and then hash] 0.000007470s
CPU Time [Block hashing using defualt writer and the hash] 0.000007329s
CPU Time [Block header hashing using hash writer] 0.000005271s

orc GC

CPU Time [Transaction serialization using two pass writer] 0.000000780s
CPU Time [Block Sequence serialization using two pass writer] 0.000001807s
CPU Time [Block serialization using two pass writer] 0.000005291s
CPU Time [Block header serialization using two pass writer] 0.000000830s

CPU Time [Transaction serialization using default writer] 0.000000930s
CPU Time [Block Sequence serailization using default writer] 0.000002420s
CPU Time [Block serialization using default writer] 0.000006576s
CPU Time [Block header serialization using default writer] 0.000001354s

CPU Time [Transaction hashing using hash writer] 0.000001478s
CPU Time [Block Sequence hashing using hash writer] 0.000005939s
CPU Time [Block hashing using hash writer] 0.000026274s
CPU Time [Block header hashing using hash writer] 0.000004191s

CPU Time [Transaction hashing using default writer and then hash] 0.000001850s
CPU Time [Block Sequence hashing using default writer and then hash] 0.000006511s
CPU Time [Block hashing using defualt writer and the hash] 0.000006459s
CPU Time [Block header hashing using hash writer] 0.000004640s

chirag-parmar · 2025-01-13T09:48:48Z

So the benchmarks collected before are biased because of the CPU cache (I verified this). So I collected new benchmarks and ran each benchmark as a different process to avoid cache hits causing skewed/biased data. The code for the benchmarks is attached after the benchmarks.

EDIT: The collected benchmarks for rlp hashing a block with varying number of transactions


import 
  eth/[rlp, common],
  times,
  std/[os, strutils],
  stew/io2,
  results

type
  Timeval {.importc: "timeval", header:"<sys/time.h>", bycopy.} = object
  
  Rusage* {.importc: "struct rusage", header:"<sys/resource.h>", bycopy.} = object
    ru_utime {.importc.}: Timeval
    ru_stime {.importc.}: Timeval
    ru_maxrss* {.importc.}: int32  # Maximum resident set size
    # ...
    ru_minflt* {.importc.}: int32  # page reclaims (soft page faults)
  
  RusageWho* {.size: sizeof(cint).} = enum
    RusageChildren = -1
    RusageSelf = 0
    RusageThread = 1

when defined(debug):
  var H_RUSAGE_SELF{.importc, header:"<sys/resource.h".}: cint
  var H_RUSAGE_CHILDREN{.importc, header:"<sys/resource.h".}: cint
  var H_RUSAGE_THREAD{.importc, header:"<sys/resource.h".}: cint
  assert H_RUSAGE_SELF == ord(RusageSelf)
  assert H_RUSAGE_CHILDREN = ord(RusageChildren)
  assert H_RUSAGE_THREAD = ord(RusageThread)

proc getrusage*(who: RusageWho, usage: var Rusage) {.importc, header: "sys/resource.h".}

const 
  accesses  = @[AccessPair(
    address: address"0x0000000000000000000000000000000000000001", 
    storageKeys: @[default(Bytes32)]
  )]

  tx = Transaction( 
    txType: TxLegacy, 
    chainId: 7.ChainId, 
    nonce: 11253.AccountNonce, 
    gasPrice: 9.GasInt, 
    maxPriorityFeePerGas: 0.GasInt, 
    maxFeePerGas: 0.GasInt, 
    gasLimit: 88920.GasInt, 
    payload: @[99, 0, 0, 0, 25, 96, 1, 1, 56, 3, 128, 99, 0, 0, 0, 25, 96, 1, 1, 96, 0, 57, 96, 0, 243, 91, 78, 30, 176, 85, 200, 234, 14, 45, 97, 73, 65, 149, 199, 11, 118, 202, 83, 30, 211, 109, 119, 168, 184, 89, 6, 38, 132, 53, 2, 237, 54, 131, 30, 141, 225, 155, 174, 92, 96, 211, 133, 53, 218, 245, 132, 17, 173, 79, 95, 241, 197, 214, 244, 196, 37, 88, 27, 34, 51, 69, 116, 64, 170, 77, 95, 191, 152, 7, 214, 85, 249, 244, 167, 67, 76, 137, 136, 37, 169, 40, 20, 131, 165, 153, 120, 158, 20, 26, 114, 99, 129, 254, 172, 229, 99, 18, 178, 251, 40, 126, 210, 155, 108, 238, 127, 2, 156, 67, 61, 199, 191, 71, 215, 72, 23, 173, 131, 213, 35, 87, 54, 248, 41, 221, 119, 31, 223, 144], 
    accessList: @[], 
    maxFeePerBlobGas: 0.u256, 
    versionedHashes: @[], 
    authorizationList: @[], 
    V: uint64(49), 
    R: 2812423844.u256, 
    S: 532553168.u256
  )

  header = Header(
    parentHash: Hash32.fromHex("0x4d24f4dddde8ab09ea900bc87492f74e44e1c3982042d0fd01673a98e72c14a6"), 
    ommersHash: Hash32.fromHex("0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347"), 
    coinbase: Address.fromHex("0x0000000000000000000000000000000000000000"), 
    stateRoot: Root.fromHex("0xa06c17a5ebaeacef3b760293e8f2092e775448c038aa7361350cde9f27e6b218"), 
    transactionsRoot: Root.fromHex("0x773faa6ccc82788a4392df241b7c6e7175fd77648fed2aaad583a528293a80bc"), 
    receiptsRoot: Root.fromHex("0x8ccc9b260110dad8161d01e72913cd27baab66809aa106a4c28a7c7a3a418b65"), 
    difficulty: 131072.u256, 
    number: 1024.BlockNumber, 
    gasLimit: 3141592.GasInt, 
    gasUsed: 891237.GasInt, 
    timestamp: EthTime(15748660), 
    extraData: @[], 
    mixHash: Bytes32.fromHex("0x378c37bd4d8692035f9d03a619d7c44a579d3b1c1c52db3096bc92a71b74aeb5"), 
    nonce: Bytes8.fromHex("0x4ea813c0c15b4215"), 
    baseFeePerGas: Opt.some(9.u256), 
  )

  blk = EthBlock(
    header: header,
    transactions: @[
      tx, tx, tx, tx,
      tx, tx, tx, tx
    ],
    uncles: @[],
  )
  
  blk80 = EthBlock(
    header: header, 
    transactions: @[
      tx, tx, tx, tx, 
      # total of 80 txs
      tx, tx, tx, tx], 
    uncles: @[], 
  )

  blk320 = EthBlock(
    header: header, 
    transactions: @[
      tx, tx, tx, tx, tx, tx, tx, tx, 
      #.. total of 320 txs
      tx, tx, tx, tx, tx, tx, tx, tx], 
    uncles: @[], 
  )
  
  blk640 = EthBlock(
    header: header, 
    transactions: @[
      tx, tx, tx, tx, tx, tx, tx, tx, 
      #... total of 640 txs
      tx, tx, tx, tx, tx, tx, tx, tx], 
    uncles: @[], 
  )
  
  blk1280 = EthBlock(
    header: header, 
    transactions: @[
      tx, tx, tx, tx, tx, tx, tx, tx, 
      #... total of 1280 txs
      tx, tx, tx, tx, tx, tx, tx, tx], 
    uncles: @[], 
  )

proc encodeOnePass[T](v: T): seq[byte] =
  var writer = initRlpWriter()

  writer.append(v)
  move(writer.finish)

proc encodeAndHash[T](v: T): Hash32 =
  keccak256(encodeOnePass(v))

# source: https://forum.nim-lang.org/t/7238
{.push checks: off.}
template benchmark(msg: string, code: untyped) =
  when not defined(windows):
    var ru: Rusage
    getrusage(RusageSelf, ru)
    var
      rss = ru.ru_maxrss
      flt = ru.ru_minflt

  when not defined(windows):
    let start = cpuTime()

  code

  when not defined(windows):
    let stop = cpuTime()

  when not defined(windows):
    getrusage(RusageSelf, ru)
    rss = ru.ru_maxrss - rss
    flt = ru.ru_minflt - flt

  echo "Benchmark: " & msg
  when not defined(windows):
    echo "Time(s)              ", stop - start
    echo "Runtime RSS (KB):     ", rss
    echo "# of page faults:     ", flt
{.pop.}

when defined(opt)
  when defined(blk):
    benchmark "encodeHash with 8 transactions":
      let bytes2 = rlp.encodeHash(blk)
  elif defined(blk80):
    benchmark "encodeHash with 80 transactions":
      let bytes2 = rlp.encodeHash(blk80)
  elif defined(blk320):
    benchmark "encodeHash with 320 transactions":
      let bytes2 = rlp.encodeHash(blk320)
  elif defined(blk640):
    benchmark "encodeHash with 640 transactions":
      let bytes2 = rlp.encodeHash(blk640)
  elif defined(blk1280):
    benchmark "encodeHash with 1280 transactions":
      let bytes2 = rlp.encodeHash(blk1280)
else:
  when defined(blk):
    benchmark "encodeHash with 8 transactions":
      let bytes2 = encodeAndHash(blk)
  elif defined(blk80):
    benchmark "encodeHash with 80 transactions":
      let bytes2 = encodeAndHash(blk80)
  elif defined(blk320):
    benchmark "encodeHash with 320 transactions":
      let bytes2 = encodeAndHash(blk320)
  elif defined(blk640):
    benchmark "encodeHash with 640 transactions":
      let bytes2 = encodeAndHash(blk640)
  elif defined(blk1280):
    benchmark "encodeHash with 1280 transactions":
      let bytes2 = encodeAndHash(blk1280)

nim compile --mm:orc -d:blk -d:release --out:bench_blk test.nim
nim compile --mm:orc -d:blk80 -d:release --out:bench_blk80 test.nim
nim compile --mm:orc -d:blk320 -d:release --out:bench_blk320 test.nim
nim compile --mm:orc -d:blk640 -d:release --out:bench_blk640 test.nim
nim compile --mm:orc -d:blk1280 -d:release --out:bench_blk1280 test.nim
nim compile --mm:orc -d:blk -d:opt -d:release --out:opt_bench_blk test.nim
nim compile --mm:orc -d:blk80 -d:opt -d:release --out:opt_bench_blk80 test.nim
nim compile --mm:orc -d:blk320 -d:opt -d:release --out:opt_bench_blk320 test.nim
nim compile --mm:orc -d:blk640 -d:opt -d:release --out:opt_bench_blk640 test.nim
nim compile --mm:orc -d:blk1280 -d:opt -d:release --out:opt_bench_blk1280 test.nim

chirag-parmar · 2025-01-13T10:36:17Z

Also want to point out that the timing improvements for encoding blocks (not hashing) using the new implementation is way more significant than for hashing with new implementations. This is because the keccak implementation adds a huge bias. The next step to improving the rlp hash algo should be optimizing the keccak implementation before optimizing the writers again.

jangko · 2025-01-13T11:03:13Z

tests/rlp/test_rlp_profiler.nim

+      let bytes13 = encodeAndHash(myTx)
+    benchmark "Block Sequence hashing using default writer and then hash":
+      let bytes14 = encodeAndHash(blkSeq)
+    benchmark "Block hashing using defualt writer and the hash":


defualt -> default

jangko · 2025-01-13T11:03:45Z

tests/rlp/test_rlp_profiler.nim

+      let bytes14 = encodeAndHash(blkSeq)
+    benchmark "Block hashing using defualt writer and the hash":
+      let bytes15 = encodeAndHash(blkSeq)
+    benchmark "Block header hashing using hash writer":


Block header hashing using hash writer -> Block header hashing using default writer and the hash

tersec · 2025-01-13T13:17:52Z

As a general note, refc performance is significantly more important to Nimbus and to IFT in general than ORC for the foreseeable future.

It's not to benchmark both, but the operative benchmarks in a short/medium-term way are refc ones.

chirag-parmar · 2025-01-15T06:42:49Z

here are refc benchmarks:

type of benchmark	Time taken by default implementation	Time taken by new implementation
Tx Encoding (single)	17us	14us
Tx Hashing (single)	30us	40us
Header Encoding	22us	15us
Header Hashing	34us	36us
Block Encoding	45us	25us
Block Hashing	72us	63us

chirag-parmar · 2025-01-15T07:09:22Z

The graphs but with refc as the garbage collector

tersec · 2025-01-15T08:58:25Z

No copyright linter will enforce this in this repository, but still good to check all the modified files in the PR and update their copyright years to 2025.

arnetheduck · 2025-01-15T10:53:35Z

something to note about benchmarking garbage-collected languages: the cost of allocation and deallocation is often not charged on the spot, but happens "randomly" - specially in a real-world application where you can't really micro-benchmark it in isolation (due to fragmentation etc).

Instead of benchmarking, the other way to reason about a change such as this is to measure/reason about the number of allocations that happen during an operation because this will ultimately determine how RLP contributes to the bigger picture in an application - the aim of the optimization is to reduce this number while not compromising on other things - for the ideal case where you're hashing an object (ie a call to rlpHash), all allocations can be done on the stack / precomputed - if this PR hits this target, it is already a success (dynamic usage of RLP is a separate topic) - the remaining unnecessary overhead will be found in zero:ing the (now) stack-allocated memory, but that's a separate concern as well.

Another way to look at it is that the objective of this PR can be reduced to "rlpHash(myobject) must not perform any heap memory alllocations" - once it fulfills this objective, it is done and we can merge / move on.

chirag-parmar · 2025-01-16T05:35:30Z

for the ideal case where you're hashing an object (ie a call to rlpHash), all allocations can be done on the stack / precomputed - if this PR hits this target, it is already a success (dynamic usage of RLP is a separate topic) - the remaining unnecessary overhead will be found in zero:ing the (now) stack-allocated memory, but that's a separate concern as well.

Noted

Another way to look at it is that the objective of this PR can be reduced to "rlpHash(myobject) must not perform any heap memory alllocations" - once it fulfills this objective, it is done and we can merge / move on.

Makes sense, there are two edge cases where dynamic allocation is unavoidable. First, are lists(static or dynamic) within dynamic sized lists. In the RLP world this would include sequences/arrays within dynamic sized sequences and objects within dynamic sized sequences. An example is the transactions field within the block object.

The second is where the type of an object doesn't fully assume the shape of the object at compile time. Examples are recurring objects for binary trees and parsed data types like JSON.

Apart from this all other cases achieve static memory allocation

chirag-parmar · 2025-01-17T03:58:19Z

https://github.com/status-im/nimbus-eth1/actions/runs/12814215402
https://github.com/status-im/nimbus-eth1/actions/runs/12814215403
https://github.com/status-im/nimbus-eth1/actions/runs/12814215405

tested against nimbus-eth1

chirag-parmar marked this pull request as ready for review December 12, 2024 17:04

chirag-parmar marked this pull request as draft December 12, 2024 17:06

chirag-parmar force-pushed the rlp-hash-opt branch from bc0089e to cc36a5c Compare December 15, 2024 10:00

chirag-parmar marked this pull request as ready for review December 15, 2024 10:53

chirag-parmar requested a review from jangko December 15, 2024 10:53

jangko reviewed Dec 19, 2024

View reviewed changes

chirag-parmar linked an issue Jan 7, 2025 that may be closed by this pull request

Implement direct RLP hashing #698

Open

jangko reviewed Jan 7, 2025

View reviewed changes

jangko reviewed Jan 13, 2025

View reviewed changes

chirag-parmar added 11 commits January 15, 2025 16:14

add a profiling test

4e8e433

basic rlp profiler

59a5f66

force expansion of memory by reducing allocation size

419f98f

optimize using two pass

7981555

fix two pass

b9636aa

add a chunked buffer implementation

058dcca

add a chunked buffer implementation

d22d9d5

multiple writers

51a5bb9

add api tests

028fdb1

fixes

27e3d94

fix double stack update problem

98be45e

chirag-parmar added 23 commits January 15, 2025 16:14

using a length tracker

1b3f494

remove code redundancy

0bbbab5

collect length in a different manner

625f377

add all tests

3645271

revert changes

35c4438

fix

9a51c27

hash writer

6cdd48e

fix

2fd4ba6

remove unwanted files

618ebab

conditional length writer execution

e476cfc

perf improvements - remove adds

e6dabc8

remove delete operations

2e5f6ca

do not use delete

220cf2e

lint code

0667c92

fix build warnings

8af1539

new benchmark contradicting results

e59befb

use a static buffer for big endian

79e2c9b

make lengths a tuple

b10b1e1

compile time evaluation of types

c3716ca

static and dynamic pending lists

7c37809

return hash32

88570b2

add block header hashing to profiler

599f89e

add a more reliable profiler

4fc0632

chirag-parmar force-pushed the rlp-hash-opt branch from b5cdf8d to 4fc0632 Compare January 15, 2025 10:44

chirag-parmar added 2 commits January 16, 2025 13:37

add/update copyright

90f68a2

took TOO long for TWO lines of code

32af6b4

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Optimize RLP serialization #765

Optimize RLP serialization #765

chirag-parmar commented Dec 11, 2024 •

edited

Loading

jangko Jan 7, 2025

chirag-parmar Jan 7, 2025

chirag-parmar Jan 7, 2025

jangko Jan 7, 2025

jangko commented Jan 7, 2025

chirag-parmar commented Jan 7, 2025 •

edited

Loading

jangko commented Jan 7, 2025

chirag-parmar commented Jan 7, 2025

chirag-parmar commented Jan 13, 2025 •

edited

Loading

chirag-parmar commented Jan 13, 2025

jangko Jan 13, 2025

jangko Jan 13, 2025

tersec commented Jan 13, 2025

chirag-parmar commented Jan 15, 2025

chirag-parmar commented Jan 15, 2025 •

edited

Loading

tersec commented Jan 15, 2025

arnetheduck commented Jan 15, 2025

chirag-parmar commented Jan 16, 2025

chirag-parmar commented Jan 17, 2025

Optimize RLP serialization #765

Are you sure you want to change the base?

Optimize RLP serialization #765

Conversation

chirag-parmar commented Dec 11, 2024 • edited Loading

Description

Rationale

Changelog

Benchmarks

jangko Jan 7, 2025

Choose a reason for hiding this comment

chirag-parmar Jan 7, 2025

Choose a reason for hiding this comment

chirag-parmar Jan 7, 2025

Choose a reason for hiding this comment

jangko Jan 7, 2025

Choose a reason for hiding this comment

jangko commented Jan 7, 2025

chirag-parmar commented Jan 7, 2025 • edited Loading

jangko commented Jan 7, 2025

chirag-parmar commented Jan 7, 2025

chirag-parmar commented Jan 13, 2025 • edited Loading

chirag-parmar commented Jan 13, 2025

jangko Jan 13, 2025

Choose a reason for hiding this comment

jangko Jan 13, 2025

Choose a reason for hiding this comment

tersec commented Jan 13, 2025

chirag-parmar commented Jan 15, 2025

chirag-parmar commented Jan 15, 2025 • edited Loading

tersec commented Jan 15, 2025

arnetheduck commented Jan 15, 2025

chirag-parmar commented Jan 16, 2025

chirag-parmar commented Jan 17, 2025

chirag-parmar commented Dec 11, 2024 •

edited

Loading

chirag-parmar commented Jan 7, 2025 •

edited

Loading

chirag-parmar commented Jan 13, 2025 •

edited

Loading

chirag-parmar commented Jan 15, 2025 •

edited

Loading