Skip to content
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

Event logs should contain only static types #35

Closed
mossid opened this issue Feb 21, 2018 · 0 comments
Closed

Event logs should contain only static types #35

mossid opened this issue Feb 21, 2018 · 0 comments

Comments

@mossid
Copy link
Contributor

mossid commented Feb 21, 2018

When dynamic types like bytes are included in a log, it makes the length of the log data not a multiple of 32. For example, this is a log data for Lock(bytes to, uint64 amount, address token)(line break for every 32 bytes == 1 word).

0000000000000000000000000000000000000000000000000000000000000060
0000000000000000000000000000000000000000000000000000000000002710
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000003
686868

The first word contains the relative position of the first element(hex 60 == dec 96). The word in that position contains the length of the bytes. The 3-byte data 686868 follows it.

It makes the parse_log in ethabi package not works. (ethabi/src/util.rs line 7-9)

if data.len() % 32 != 0 {
    return Err(ErrorKind::InvalidData.into());
}

To solve this problem, we have to change every bytes in solidity files into bytes32. On the frontend side, we can either 1. hash the input data to make it bytes32 or 2. accept bytes only whose length is less than 32.

So the api should be modified as:

lock(bytes32 to, uint64 value, address token) external payable returns (bool);
event Lock(bytes32 to, uint64 value, address token);

unlock(address[2] addressArg, uint64 value, bytes32 chain, uint16[] idxs, uint8[] v, bytes32[] r, bytes32[] s) external returns (bool)

unlock also has to take bytes32 in favor of #32

alpe pushed a commit to alpe/peggy that referenced this issue Sep 16, 2020
Bootstrapping process design

In this patch I outline a detailed and I think workable bootstrapping
process that can start Peggy in a decentralized manner without creating
too much manual consensus burden.
zmanian pushed a commit that referenced this issue Jun 19, 2021
* reup testnet gravity nodes (and cache go deps more effectively)

* dockerignore - don't send _any_ rust target folders up to dockerd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants