GithubHelp home page GithubHelp logo

etcdevteam / etcommon-rs Goto Github PK

View Code? Open in Web Editor NEW
21.0 21.0 14.0 554 KB

Apache-2 licensed common Ethereum structs shared by crates

License: Apache License 2.0

Rust 99.37% Nix 0.63%
ethereum ethereum-classic

etcommon-rs's People

Contributors

axelnennker avatar eh2406 avatar elichai avatar gagarin55 avatar mersinvald avatar r8d8 avatar sorpaas avatar splix avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

etcommon-rs's Issues

Move away from elastic-array-plus 0.10 (will panic in future rust)

Hello! I'm coming to this repo from rust-lang/rust#99389, and am making an issue for etcommon-block, etcommon-block-core, etcommon-rlp, etcommon-trie, etcommon-trie-test.

These were all crates that depend on elastic-array-plus in a way that will panic in future rust.

It looks like elastic-array-plus is just an array vec, so any array vector crate would work to replace it. https://crates.io/crates/arrayvec might be a good choice.

rlp: slice-like decoder

Make a trait decoder that keeps the current slicing. This standardizes all the current slice-like decoder we have.

rip: UB in dependency

You seem to depend on elastic-array-plus, which blatantly undefined behavior (misusing get_unchecked out of bounds, having uninitialized T).

Since it is just a bad reimplementation of tinyvec, maybe consider switching to tinyvec?

Refactoring and initial structural design

(This was originally written in org-mode. So I'll keep the format.)

Some refactoring changes include:

- Use short lib names for all crates
- Dismiss patch version requirements
- =worldstate= to =trie=
- =util= to =hex=
- =Consensus= trait in =block= that allows validate an existing block
  and mining a new block

The integrated =etcommon= crate will contain a general Ethereum
blockchain interface. This interface will be built upon a smaller
interface crated in =blockchain=, which contains a general interface
for a blockchain.

A blockchain has its transaction format, account address format,
account state format. The account address format and the account state
format forms a map that defines the world state. A transition rule
defines the way it transfer from one world state to the next world
state. Each transition can also creates additional data defined by the
additional format.

Given a set of transactions, world state after applying all
transactions using the transition rules, the additional data created,
the interface is expected to be able to construct a =non-consensus=
new block. The consensus function is expected to turn that into a
=consensus= new block using its =mine= function.

=etcommon= simply has the transaction format set as =Transaction=,
account address format as =Address=, account state format as
=Account=, transition rule defined as a function using EVM (being
generic in =etcommon=, but we know it's SputnikVM), additional data
defined as =(TransactionReceipt, Vec<Log>)=. Consensus is generic, it
can either be =FakeConsensus= (used by =etestrpc=), or =ethash= (by
=etclient=). We see that =etcommon= reduces the amount of generic
traits to two: consensus and transition rules.

Those rules does not care about parallel execution at all -- it is
expected that transactions are always in sequence, and it's the actual
client's responsibility to implement parallel execution and figure out
the sequence, if needed (if so, world state must allow "merging").

Then for =etestrpc= and =etclient=, the job is to simply use the above
interface to implement an event loop. For =etestrpc=, the event loop
would simply be a timeout that mines a new block every ten
seconds. For =etclient=, the event loop would be using =devp2p=. It is
expected that the actual code in =etestrpc= and =etclient= would be
very short.

etcommon-rlp fails with no_std on new rust versions

Hey,
I'm using etcommon-rlp = { version = "0.2.3", default-features = false}
I updated rustc to: rustc 1.29.0-nightly (31f1bc7b4 2018-07-15)
And cargo to: cargo 1.29.0-nightly (af9e40c26 2018-07-05)
Now I get this error while compiling:

   Compiling etcommon-hexutil v0.2.3 (https://github.com/enigmampc/etcommon-rs.git?rev=develop#f229bdd7)                                                                                                                                                                       
error[E0432]: unresolved import `alloc::String`                       ] 11/103: typenum, semver-parser, sgx_build_helper, rayon, etcommon-hexutil                                                                                                                              
  --> /root/.cargo/git/checkouts/etcommon-rs-e1e8f285bcf80a62/f229bdd/hexutil/src/lib.rs:13:13
   |
13 | use alloc::{String, Vec};
   |             ^^^^^^ no `String` in the root. Did you mean to use `string`?

error[E0432]: unresolved import `alloc::Vec`
  --> /root/.cargo/git/checkouts/etcommon-rs-e1e8f285bcf80a62/f229bdd/hexutil/src/lib.rs:13:21
   |
13 | use alloc::{String, Vec};
   |                     ^^^ no `Vec` in the root. Did you mean to use `vec`?

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0432`.

And if I try using a stable version:
rustc 1.27.2 (58cc626de 2018-07-18) and cargo 1.27.0 (1e95190e5 2018-05-27).
I get:

elichai2@elichai2-YOGA-720:~/gits/etcommon-rs/rlp$ cargo build --no-default-features
   Compiling elastic-array-plus v0.9.1
   Compiling etcommon-hexutil v0.2.3 (file:///home/elichai2/gits/etcommon-rs/hexutil)
error[E0554]: #![feature] may not be used on the stable release channel
 --> hexutil/src/lib.rs:2:35
  |
2 | #![cfg_attr(not(feature = "std"), feature(alloc))]
  |                                   ^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: Could not compile `etcommon-hexutil`.
warning: build failed, waiting for other jobs to finish...
error[E0554]: #![feature] may not be used on the stable release channel
 --> /home/elichai2/.cargo/registry/src/github.com-1ecc6299db9ec823/elastic-array-plus-0.9.1/src/lib.rs:2:35
  |
2 | #![cfg_attr(not(feature = "std"), feature(alloc))]
  |                                   ^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: Could not compile `elastic-array-plus`.

To learn more, run the command again with --verbose.

trie: nightly builds failed

The newest nightly version reports this error:

C:\Users\appveyor\.cargo\registry\src\github.com-1ecc6299db9ec823\etcommon-trie-0.3.7\src\merkle\nibble.rs:96:24
   |
96 |             ret[i / 2] |= nibble[i].into();
   |                        ^^
error: aborting due to previous error

trie: gabbage collectable insert and remove for Merkle

Allow two root trie types: persistent and temporary. Allow conversion between those two. Add DB level support.

Add insert and remove function for trie that returns a new trie. (Needs to deal with #13 first.) Also allow multiple insertion and removal in one function.

Rename lib name to be without `etcommon` prefix

It's not quite feasible that a library that depends on etcommon-bigint would use yet another crate called bigint. So it's pretty safe to rename the lib name to just bigint. For others as well.

The only one that might be in trouble is etcommon-util. It might be a good idea to just rename this crate or try to put read_hex elsewhere.

Inconsistent naming for etcommon-bigint

To use etcommon-bigint you need to specify it as etcommon-bigint in your Cargo.toml but as bigint in your main.rs.

Example:
Cargo.toml:

[dependencies]
etcommon-bigint = "0.2.9"

main.rs:

extern crate bigint;

I believe this mismatch is due to the following in https://github.com/ETCDEVTeam/etcommon-rs/blob/master/bigint/Cargo.toml#L11:

[lib]
name = "bigint"

I realize changing this now would break dependencies but it is a bit confusing when trying to work with the library so maybe adding a note to the docs would be helpful? If so I can submit a PR next week.

Bumping & Publishing new versions

Hi,
After all the new changes there are some crates that need version bumps and publishing.

Needs bumping(and publishing) - etcommon-trie-rocksdb .
Already bumped, Needs publishing: etcommon-rlp, etcommon-hexutil.

Thank you,
Elichai.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.