foundry
foundry copied to clipboard
CodeChain-io
A programmable open source blockchain engine
Foundry host eventually has to use the 0th validator given by `UpdateConsensus`, as the proposer. This will remove old CodeChain proposer selection logic https://github.com/CodeChain-io/foundry/pull/602#pullrequestreview-556853470. And also, to express complicated staking...
It sometimes fails with ``` thread 'track_blocks' panicked at 'called `Result::unwrap()` on an `Err` value: Connect(Io(Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }))', /home/junha/Projects/foundry/integration-test/src/lib.rs:147:47 ```
Bumps [ini](https://github.com/isaacs/ini) from 1.3.5 to 1.3.8. Commits a2c5da8 1.3.8 af5c6bb Do not use Object.create(null) 8b648a1 don't test where our devdeps don't even work c74c8af 1.3.7 024b8b5 update deps, add linting...
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot] avatar"){kind=avatar}
We decided not to use 0x in the hex representation of binary data. The current implementation of Deserialize of ed25519 and x25519 is using 0x as a prefix.
It was an intention to move it before in https://github.com/CodeChain-io/foundry/issues/538. It was missed in the https://github.com/CodeChain-io/foundry/pull/574
## Types Eventually, we will have only 3 types for validators. 1. `ctypes::Validator` - It has two fields: `public_key` and `weight`. 2. `ctypes::ValidatorSet` - It is a newtype of `Vec`,...
Currently there is an option to provide single `TxOwner` to cover all of the Tx types implemented by a module. In relation to #555, it's more natural to expect multiple...
We should separate out the block related methods from TxOwner in the following grounds: 1. Some modules not implementing any Tx may serve `TxOwner`s and may want to have chances...