Pass inputs and root commitment to dispute client #78
Conversation
stephenctw
commented
Oct 7, 2024
- pass inputs and root commitment to dispute client (both Rust and Lua)
- implement a db so prt-rs can cache and recover inputs and commitments from a restart
GCdePaula
left a comment
There was a problem hiding this comment.
I think you can rename the directory from prt/prt-rs to prt/client-rs. Also, you could split the crates in two: core and client (the former is only a lib, the latter has a main function).
Alloy 0.4 is out, we could update to it. I think the main hurdle will be updating the bindings.
I think it might make sense to make the root of the repo a Rust workspace. This should make everything "compatible" version-wise, specially regarding alloy. When you specify the members of a workspace, it's possible to put a path (like cartesi-rollups/node/reader). If we do this, only in the root should there be a Cargo.lock.
I think it may also make sense to create a Makefile at the root. One target should be to create the bindings (recursively calling the bindings makefile), and another target (depends on bindings) should build the Rust workspace. Other targets for CI like rustfmt, cargo test, cargo clippy (clippy should only be warnings for now). Other targets for building and testing smart contracts (which could be "recursive", in the sense that they call an inner makefile). I don't think the inner compute tests should have a target on this root makefile.
Good work on the tests!
| } | ||
| } | ||
|
|
||
| fn snapshot(&self, epoch_number: u64, input_index_in_epoch: u64) -> Result<Option<String>> { |
There was a problem hiding this comment.
It is to get the path of machine snapshot of given (epoch_number, input_index_in_epoch). The node would pass snapshot(epoch_number, 0)to be the initial machine path for the dispute client.
| local function build_big_machine_commitment(base_cycle, log2_stride, log2_stride_count, machine) | ||
| local function build_big_machine_commitment(base_cycle, log2_stride, log2_stride_count, machine, snapshot_dir) | ||
| local machine_state = machine:run(base_cycle) | ||
| if save_snapshot then |
There was a problem hiding this comment.
If save_snapshot is a global variable, I think I prefer that snapshot_dir also be a global variable, unless it's changing.
There was a problem hiding this comment.
It could change occasionally because it's /dispute_data/$root_tournament_address.
| #[derive(Deserialize)] | ||
| struct TempInputsAndLeafs { | ||
| leafs: Vec<TempLeaf>, // Use a temporary struct for deserialization | ||
| inputs: Option<Vec<String>>, // Temporarily keep inputs as vec of String |
There was a problem hiding this comment.
If it's possible for Vec<u8> instead of String, I think it's preferable, but not a problem otherwise.
There was a problem hiding this comment.
Is String encoding-agnostic? Inputs may not be valid UTF-8 byte arrays.
There was a problem hiding this comment.
Is
Stringencoding-agnostic? Inputs may not be valid UTF-8 byte arrays.
I think the one who generates the file should make sure it's hex string like "0xaabb1234" than pure binary blob.
There was a problem hiding this comment.
Oh, it's hex-encoded! Gotcha.
| impl<'de> Deserialize<'de> for InputsAndLeafs { | ||
| fn deserialize<D>(deserializer: D) -> std::result::Result<Self, D::Error> | ||
| where | ||
| D: Deserializer<'de>, |
There was a problem hiding this comment.
Is this really necessary? I feel there are macros in serde that allows you to configure the deserializer. Like, it's rare to need to implement it by hand.
| #[derive(Debug, Serialize)] | ||
| pub struct InputsAndLeafs { | ||
| inputs: Vec<Vec<u8>>, | ||
| leafs: Vec<(Vec<u8>, u64)>, |
There was a problem hiding this comment.
I think we should create a proper struct with fields for leafs. It will be clearer that it's a hash and repetitions. Also, the hash should have a fixed size like [u8; 32].
It's ok to use this as an intermediary representation, but it makes sense to convert it to a nicer type later. Unless this is only used to populate the DB. Then I think a comment might be enough, and not make it public.
| let hex_string = leaf.hash.strip_prefix("0x").unwrap_or(&leaf.hash); | ||
| (hex::decode(hex_string).unwrap(), leaf.repetitions) | ||
| }) |
There was a problem hiding this comment.
Alloy has hex decode functionalities, which I believe can handle 0x.
|
I've left a few comments which could be on a different PR actually. The work looks really good, maybe we should merge it first and then tackle the broader comments. |
92eb775 to
a986f29
Compare
I've addressed most of the comments except the one that suggests making the entire project a Rust workspace. I think that can be on a separate PR. I created an issue to track it. |