From f38b8460b893848ea85e331643b3379a4ff6d7ce Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sat, 19 Oct 2024 00:30:41 +0300 Subject: [PATCH 1/4] Update README.md --- chapter1/bls-multisig/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapter1/bls-multisig/README.md b/chapter1/bls-multisig/README.md index 6c89150..0ea6291 100644 --- a/chapter1/bls-multisig/README.md +++ b/chapter1/bls-multisig/README.md @@ -74,7 +74,7 @@ alloy::sol! { This will generate bindings for `BLSMultisig` and `BLS`, allowing us to reuse the same G1/G2 structures in Rust code. -Now, let's define helpers for converting between our contract's structures and `blst` types. `blst` provides serialization methods for both G1 and G2 points which are a bit different from the format defined in [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537). Converting between the two requires some bit manipulation. +Now, let's define helpers for converting between our contract's structures and `blst` types. `blst` provides serialization methods for both G1 and G2 points which are a bit different from the format defined in [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537). Converting between the two requires some bit of manipulation. ```rust use blst::min_pk::{PublicKey, Signature}; From cbf2fe00a88fcefbb61bf8fde0ffc74757b321c9 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sat, 19 Oct 2024 00:34:38 +0300 Subject: [PATCH 2/4] Update README.md --- chapter1/simple-7702/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/chapter1/simple-7702/README.md b/chapter1/simple-7702/README.md index 9420c77..292aa52 100644 --- a/chapter1/simple-7702/README.md +++ b/chapter1/simple-7702/README.md @@ -59,7 +59,7 @@ $ cast code $ALICE_ADDRESS 0xef0100... ``` -Note that in this over-simplified example, you’ll already see some issues e.g. anyone could send the transaction to any address on Alice behalf, since there’s such restriction in the signed authorization. To address this issue, you would need to add additional setup functions which would be called on user's bytecode once delegation has been applied. +Note that in this over-simplified example, you’ll already see some issues e.g. anyone could send the transaction to any address on Alice's behalf, since there’s such restriction in the signed authorization. To address this issue, you would need to add additional setup functions which would be called on user's bytecode once delegation has been applied. ## Testing with foundry @@ -72,4 +72,4 @@ vm.etch(ALICE, bytes.concat(hex"ef0100", abi.encodePacked(contractToDelegate))); This cheat code allows you to **simulate that ALICE's account is no longer a regular EOA but a contract**(like `P256Delegation`) and then test how delegations or transactions behave from that new "smart contract" EOA. -You can check out complete example in [SimpleDelegateContract.t.sol](../contracts/test/SimpleDelegateContract.t.sol) +You can check out the complete example in [SimpleDelegateContract.t.sol](../contracts/test/SimpleDelegateContract.t.sol) From 1f32b185cf03df6496d3c2574c6e999909e6786c Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sat, 19 Oct 2024 00:35:07 +0300 Subject: [PATCH 3/4] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 98ff2eb..a510793 100644 --- a/README.md +++ b/README.md @@ -5,7 +5,7 @@ This repository provides a step-by-step walk through for builders interested in ### Chapter 1 - [Simple Example for EIP-7702](./chapter1/simple-7702/): Showcases how EIP-7702 transactions work - [Delegate an account to a p256 key](./chapter1/delegate-p256/): Describes how EIP-7702+EIP-7212 provide the ability to sign a message with a P256 key -- [BLS Multisig](./chapter1/bls-multisig/): In-depth walk-through how to implement a Multisig based on BLS signatures verified through precompiles from EIP-2537 +- [BLS Multisig](./chapter1/bls-multisig/): In-depth walk-through of how to implement a Multisig based on BLS signatures verified through precompiles from EIP-2537 - [EOF](./chapter1/eof/): Instructions on how to deploy and inspect contracts in the new EOF format ### Build & Test From c3f7745bb2e2468c137858db79ef6dbbdbd0325b Mon Sep 17 00:00:00 2001 From: Matthias Seitz Date: Thu, 31 Oct 2024 23:11:08 +0100 Subject: [PATCH 4/4] Update chapter1/bls-multisig/README.md --- chapter1/bls-multisig/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapter1/bls-multisig/README.md b/chapter1/bls-multisig/README.md index 0ea6291..6c89150 100644 --- a/chapter1/bls-multisig/README.md +++ b/chapter1/bls-multisig/README.md @@ -74,7 +74,7 @@ alloy::sol! { This will generate bindings for `BLSMultisig` and `BLS`, allowing us to reuse the same G1/G2 structures in Rust code. -Now, let's define helpers for converting between our contract's structures and `blst` types. `blst` provides serialization methods for both G1 and G2 points which are a bit different from the format defined in [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537). Converting between the two requires some bit of manipulation. +Now, let's define helpers for converting between our contract's structures and `blst` types. `blst` provides serialization methods for both G1 and G2 points which are a bit different from the format defined in [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537). Converting between the two requires some bit manipulation. ```rust use blst::min_pk::{PublicKey, Signature};