Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[KMS] Trim signature bytes for RLP encoding (#944)
Fixes issues that sometimes invalid raw transaction bytes are generated when using AWS. E.g. ``` 0xf86b0285012a05f2008261a8948b733353ce21ebd8eb5ffd9f49d57830942e88158769ec95a3fa70008025a04f9dd75069b51d36ec47b5bf68e6c45f8b854cf17a661e734e7a7c651240eeaca00044280475c3d355c44829ac93118b4ebe044356185c1c08724c8bcfebbd4b3d ``` The issue seems to be that we use the web3 `Signature` type, which encodes s and r as H256 (really they are just points on a curve). Later in the code, we RLP encode those value to create the signed raw transaction. Ethereum requires, at least in the context of signatures, the minimal length RLP encoding for values (no leading 0s). [H256's RLP encoding](https://rust.velas.com/src/impl_rlp/lib.rs.html#50-72) implementation does not trim leading 0s. U256's implementation however does trim leading 0s ([source](https://rust.velas.com/src/impl_rlp/lib.rs.html#21-46)). This PR addresses the issue by converting the H256 into U256 just before RLP encoding it. ### Test Plan Things still work: ``` cargo run --example kms ``` To ensure we can "just" trim the bytes of a leading 0 signature I used this raw tx that our backend generated (cf above), loaded it into https://toolkit.abdk.consulting/ethereum#rlp,transaction, removed the leading 0s from the last element and then successfully decoded it in https://tools.deth.net/tx-decoder
- Loading branch information