-
Notifications
You must be signed in to change notification settings - Fork 0
PoC: modularize executor and simplify Wasm I/O with permissionless and permissioned scenarios #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
s8sato
wants to merge
2
commits into
init
Choose a base branch
from
main
base: init
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,87 @@ | ||
| # Executor Modularization & WasmInstruction I/O Simplification PoC | ||
|
|
||
| This proof-of-concept explores splitting Hyperledger Iroha’s _Executor_ into modular pieces and slimming down _WasmInstruction_ I/O. The inspiration comes from: | ||
|
|
||
| - <https://github.com/hyperledger-iroha/iroha/issues/5357> | ||
| - <https://github.com/hyperledger-iroha/iroha/issues/5358> (see state-transition diagram) | ||
|
|
||
| These occupy a key position within tracking issue [#5356](https://github.com/hyperledger-iroha/iroha/issues/5356): | ||
|
|
||
|  | ||
|
|
||
| ## Objective | ||
|
|
||
| Can we cleanly separate instruction execution into three roles? | ||
|
|
||
| 1. _WasmInstruction_: collects read/write intents without directly mutating state | ||
| 2. _Authorizer_: evaluates intents against permission rules (approve or reject) | ||
| 3. _Host runtime_: initiates the instruction flow, batches intents for the authorizer, and applies them to state | ||
|
|
||
| Success means smaller, testable components, fewer FFI round-trips, and clearer extension points. | ||
|
|
||
| ## Repository Structure | ||
|
|
||
| ```text | ||
| . | ||
| ├── guest/ | ||
| │ ├── authorizer/ — Wasm component that enforces permissions | ||
| │ └── instruction/ — Wasm component that submits read/write intents | ||
| ├── host/ — Rust runtime and tests | ||
| ├── wit/ — Shared WIT interfaces | ||
| └── README.md | ||
| ``` | ||
|
|
||
| ## Building & Testing | ||
|
|
||
| ### Prerequisites | ||
|
|
||
| ```bash | ||
| rustup target add wasm32-wasip2 | ||
| ``` | ||
|
|
||
| ```bash | ||
| cargo add wit-bindgen | ||
| ``` | ||
|
|
||
| ### Guest components | ||
|
|
||
| ```bash | ||
| cargo build --target wasm32-wasip2 --manifest-path guest/instruction/Cargo.toml | ||
| ``` | ||
|
|
||
| ```bash | ||
| cargo build --target wasm32-wasip2 --manifest-path guest/authorizer/Cargo.toml | ||
| ``` | ||
|
|
||
| ### Host tests | ||
|
|
||
| ```bash | ||
| cargo test --package host --lib | ||
| ``` | ||
|
|
||
| ```bash | ||
| cargo test --package host --lib -- tests::instruction_flows --exact --show-output | ||
| ``` | ||
|
|
||
| Compare the test steps to the #5358 state-transition diagram for clarity. | ||
|
|
||
| ## Developer Notes | ||
|
|
||
| ### Host vs. guest, imports vs. exports | ||
|
|
||
| - `wasmtime::component::bindgen!` is used on the _host_ side to implement _import_ functions. | ||
| - `wit_bindgen::generate!` is used on the _guest_ side to implement _export_ functions. | ||
|
|
||
| ### [Component model](https://component-model.bytecodealliance.org/introduction.html) trade-offs | ||
|
|
||
| - Removes all `unsafe` blocks around FFI calls, making future development and maintenance easier: | ||
| > By expressing higher-level semantics than integers and floats, it becomes possible to statically analyse and reason about a component's behaviour - to enforce and guarantee properties just by looking at the surface of the component. | ||
| - Wasm _components_ typically produce larger binaries than classic _modules_—keep that in mind. | ||
|
|
||
| ### Future developer experience | ||
|
|
||
| - Consider `guest/instruction/src/lib.rs` as a reference implementation of smart contracts and trigger executables. It’s intentionally verbose now; later we can introduce syntax sugars. | ||
|
|
||
| --- | ||
|
|
||
| _This PoC is experimental and exists solely to test the feasibility of the referenced Iroha issues._ |
This file was deleted.
Oops, something went wrong.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7,3 +7,4 @@ edition.workspace = true | |
| crate-type = ["cdylib"] | ||
|
|
||
| [dependencies] | ||
| wit-bindgen = { workspace = true} | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,91 @@ | ||
| use poc::wit::types::*; | ||
|
|
||
| wit_bindgen::generate!({ | ||
| world: "universe", | ||
| path: "../../wit", | ||
| }); | ||
|
|
||
| struct Authorizer; | ||
|
|
||
| /// Default implementation for permission validation. | ||
| impl Guest for Authorizer { | ||
| fn read_request(_args: String) -> ReadSet { | ||
| unimplemented!("boilerplate"); | ||
| } | ||
|
|
||
| fn read_approval(signals: ReadSet, receptors: AllowSet) -> bool { | ||
| let mut signals = signals; | ||
| signals.inner.retain(|signal| { | ||
| let approved = receptors.inner.iter().any(|receptor| { | ||
| let captures = receptor.key.captures(&signal.key); | ||
| let NodeValueAllow::AccountAsset(AccountAssetA { bit_mask }) = receptor.value; | ||
| let passes = 0b0000_0001 & !bit_mask == 0; | ||
| captures && passes | ||
| }); | ||
|
|
||
| !approved | ||
| }); | ||
|
|
||
| signals.inner.is_empty() | ||
| } | ||
|
|
||
| fn write_request(_view: ViewSet, _args: String) -> WriteSet { | ||
| unimplemented!("boilerplate"); | ||
| } | ||
|
|
||
| fn write_approval(signals: EventSet, receptors: AllowSet) -> bool { | ||
| let mut signals = signals; | ||
| signals.inner.retain(|signal| { | ||
| let NodeValueEvent::AccountAsset(AccountAssetE { status_bit }) = signal.value; | ||
| let receptors = receptors | ||
| .inner | ||
| .iter() | ||
| .filter(|receptor| receptor.key.captures(&signal.key)); | ||
| let Some(bit_mask_union) = receptors | ||
| .map(|entry| { | ||
| let NodeValueAllow::AccountAsset(AccountAssetA { bit_mask }) = entry.value; | ||
| bit_mask | ||
| }) | ||
| .reduce(|acc, bit| acc | bit) | ||
| else { | ||
| return false; | ||
| }; | ||
|
|
||
| let approved = status_bit & !bit_mask_union == 0; | ||
| !approved | ||
| }); | ||
|
|
||
| signals.inner.is_empty() | ||
| } | ||
| } | ||
|
|
||
| export!(Authorizer); | ||
|
|
||
| // TODO: move common types to separate crate from host | ||
| pub trait Capture<T> { | ||
| fn captures(&self, candidate: &T) -> bool; | ||
| } | ||
|
|
||
| impl Capture<NodeKey> for FuzzyNodeKey { | ||
| fn captures(&self, key: &NodeKey) -> bool { | ||
| let ( | ||
| FuzzyNodeKey::AccountAsset(FuzzyCompositeKey { e0: z0, e1: z1 }), | ||
| NodeKey::AccountAsset(CompositeKey { e0, e1 }), | ||
| ) = (self, key); | ||
| z0.as_ref().is_none_or(|z0| z0 == e0) && z1.as_ref().is_none_or(|z1| z1 == e1) | ||
| } | ||
| } | ||
|
|
||
| impl Capture<FuzzyNodeKey> for FuzzyNodeKey { | ||
| fn captures(&self, candidate: &FuzzyNodeKey) -> bool { | ||
| let ( | ||
| FuzzyNodeKey::AccountAsset(FuzzyCompositeKey { e0: z0, e1: z1 }), | ||
| FuzzyNodeKey::AccountAsset(FuzzyCompositeKey { e0, e1 }), | ||
| ) = (self, candidate); | ||
| z0.as_ref() | ||
| .is_none_or(|z0| e0.as_ref().is_some_and(|e0| z0 == e0)) | ||
| && z1 | ||
| .as_ref() | ||
| .is_none_or(|z1| e1.as_ref().is_some_and(|e1| z1 == e1)) | ||
| } | ||
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| [package] | ||
| name = "instruction" | ||
| version.workspace = true | ||
| edition.workspace = true | ||
|
|
||
| [lib] | ||
| crate-type = ["cdylib"] | ||
|
|
||
| [dependencies] | ||
| serde = { workspace = true } | ||
| serde_json = { workspace = true } | ||
| wit-bindgen = { workspace = true} |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,81 @@ | ||
| use poc::wit::types::*; | ||
| use serde::Deserialize; | ||
|
|
||
| wit_bindgen::generate!({ | ||
| world: "universe", | ||
| path: "../../wit", | ||
| }); | ||
|
|
||
| struct SupplyAll; | ||
|
|
||
| #[derive(Debug, Deserialize)] | ||
| struct Args { | ||
| // Name of the asset to supply | ||
| asset: String, | ||
| // Account balances below this threshold will be supplied | ||
| threshold: u32, | ||
| // Amount to supply to accounts | ||
| supply_amount: u32, | ||
| // The supplier account | ||
| supplier: String, | ||
| } | ||
|
|
||
| impl Guest for SupplyAll { | ||
| fn read_request(args: String) -> ReadSet { | ||
| let args: Args = serde_json::from_str(&args).expect("wrong args"); | ||
|
|
||
| let inner = vec![ReadEntry { | ||
| key: FuzzyNodeKey::AccountAsset(FuzzyCompositeKey { | ||
| e0: None, | ||
| e1: Some(args.asset.to_string()), | ||
| }), | ||
| value: NodeValueRead::AccountAsset, | ||
| }]; | ||
|
|
||
| ReadSet { inner } | ||
| } | ||
|
|
||
| fn read_approval(_signals: ReadSet, _receptors: AllowSet) -> bool { | ||
| unimplemented!("boilerplate"); | ||
| } | ||
|
|
||
| fn write_request(view: ViewSet, args: String) -> WriteSet { | ||
| let args: Args = serde_json::from_str(&args).expect("wrong args"); | ||
|
|
||
| let inner = view | ||
| .inner | ||
| .into_iter() | ||
| .filter_map(|entry| { | ||
| let NodeValueView::AccountAsset(value) = entry.value; | ||
| (value.balance < args.threshold).then(|| { | ||
| vec![ | ||
| WriteEntry { | ||
| key: entry.key, | ||
| value: NodeValueWrite::AccountAsset(AccountAssetW::Receive( | ||
| args.supply_amount, | ||
| )), | ||
| }, | ||
| WriteEntry { | ||
| key: NodeKey::AccountAsset(CompositeKey { | ||
| e0: args.supplier.clone(), | ||
| e1: args.asset.clone(), | ||
| }), | ||
| value: NodeValueWrite::AccountAsset(AccountAssetW::Send( | ||
| args.supply_amount, | ||
| )), | ||
| }, | ||
| ] | ||
| }) | ||
| }) | ||
| .flatten() | ||
| .collect(); | ||
|
|
||
| WriteSet { inner } | ||
| } | ||
|
|
||
| fn write_approval(_signals: EventSet, _receptors: AllowSet) -> bool { | ||
| unimplemented!("boilerplate"); | ||
| } | ||
| } | ||
|
|
||
| export!(SupplyAll); | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a thread for discussing the separation of the read side and the write side: #1 (comment)
We may be able to support adding as many
as the user needs before moving on to
write_request.Even then, there’s value in batching wherever possible, and in most simple cases a single read will be sufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds like adding an arbitrary amount of static methods that users may or may not use. I think this isn't a flexible design choice and a dynamic approach is preferable. It is also still hard to think about smart contract design in the sense of "multi-stage reading".
Yes, but that's up to the implementer of a smart contract. I think we shall provide an instrument to make batched reads, but not enforce it, and not limit all reads to a fixed point of smartcontract execution. In other words, leave it the same as it is now, but add a mechanism to make batched queries.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that it’s not common to design a smart contract that limits read access to a finite number before writing. The previous design—where reads and writes could be interleaved in any order and as many times as needed—is more typical, so I may need to revise my plan.
The original goal of this design was to minimize the performance overhead of permission checks on every access in Iroha (#4756). Currently, permission tokens are re-aggregated on each check, but in the PoC the union of permissions obtained on the first read access is cached as part of the instruction’s transition state and reused on the next write access.
This caching effect remains effective even as the number of accesses grows and may be sufficiently powerful. However, it would be even more ideal to cache the account permissions on the authorizer side rather than the host side, since that would suppress the problematic serialize/deserialize operations on the FFI boundary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have an idea on how to cache permissions on the authorizer side?
As I understand, that would require a "stateful authorizer (executor, validator) session" during the time of a single smartcontract execution.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, as long as we adhere to the component model, memory sharing isn’t allowed and the authorizer can’t cache, so de/serialization will be inevitable per request.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Design Revision Proposal
For write access, since allowing arbitrary invocations would add complexity without sufficient benefit, we plan to keep it limited to a single invocation. In more complex use cases, it will still be possible to include a subsequent Wasm instruction call within that single write access.
For read access, the outline of the planned changes is as follows:
Instead of having the guest define this read-request:
the host will provide a generic read function:
The guest can use this read function any number of times to implement the write-request function:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps the host could also provide a generic function for writes without adding extra complexity:
I’ll try out a few PoC implementations.