๐ง This repo is not maintained anymore please submit your feature proposal or bug report to Catalyst Core.
input-output-hk / chain-libs Goto Github PK
View Code? Open in Web Editor NEWblockchain libs
License: Apache License 2.0
blockchain libs
License: Apache License 2.0
๐ง This repo is not maintained anymore please submit your feature proposal or bug report to Catalyst Core.
UpdateState::process_proposals has bug in my opinion, which leads to problem in which proposal which was not accepted before proposal_expiration period won't be removed from proposal collection at all.
there are two conditions in mentioned method:
if prev_date.epoch < new_date.epoch
and
else if proposal_state.proposal_date.epoch + settings.proposal_expiration
> new_date.epoch
if we apply proposal in the current epoch (let's say epoch 0 and our proposal_expiration
is any value different than 0, then it's impossible to satisfy condition proposal_state.proposal_date.epoch + settings.proposal_expiration < new_date.epoch
=> 0 + 1 > 1 = false
and then new_date.epoch will be increased i believe if we time proceeds, so above condition will be never met and therefore proposal will stay in collection forever).
In different scenario in which we apply proposal for epoch in the future let's say epoch 5 (while we are at epoch 0) then if proposal won't be accepted in epoch 0, then it will be immediately removed from proposals in process_proposals
. (5 + 0 > 0 = true)
To fix this situation we need to reverse condition:
else if proposal_state.proposal_date.epoch + settings.proposal_expiration
< new_date.epoch
This will solve first scenario in epoch 2 (0+ 1 < 2 = true) and in second scenario proposal won't be removed from proposal before its time will come (5 + 0 < 0 =false )
BlockHash -> ..
) and Sequential / Geographical data structure (data height, date)Allow the system to start at a defined offset epoch=N
instead of assuming epoch=0
, which need to de-hardcode couple of place that expect to start at date=0.0
track down the votes in the ledger's vote plan state manager
the BlockStore
method name is_ancestor
is misleading. Ok(None)
is returned when there are no ancestral relations.
Perhaps the method should be renamed and a purpose-specific enum can be introduced for self-descriptive explanation of the success cases.
In many immutable places, we keep Vec<T>
instead of using Box<[T]>
which save 8 bytes and also represent immutability better than Vec.
Dependabot couldn't parse the Cargo.toml found at /chain-core/Cargo.toml
.
The error Dependabot encountered was:
Dependabot::DependencyFileNotParseable
add specialisation fee for the vote plan certificate
the uniqueness property of utxo is hard to satisfy when the component are just accounts, since the nonce is associated with the witness only.
The method DigestOf::digest_with
is arguably too loose for library API: it allows any closure to calculate a digest of an object, which is however, tied to the object type by its type parameter.
To reduce possibility of sneaky errors, this method should be replaced by a different method using a new trait similar to std::hash::Hash
, which object types would need to implement to support calculation of a digest on their contents in a single canonical way.
DigestOf::coerce
suffers from similar looseness, but at least its intent is explicit in the code. Its only usage so far is in a quickcheck Arbitrary
impl for DigestOf
, which is rather hackish.
All dependencies of tower-grpc in its git master branch have graduated to be versioned on crates.io. It can be used with a crates.io version of tower-hyper as the HTTP stack. This means we can achieve build stability with revision-locked tower-grpc, but the HTTP stack crate needs to be switched from tower-h2 to tower-hyper.
client::Background
(tower-rs/tower-hyper#46)client::ConnectFuture
public (tower-rs/tower-hyper#48)client::ResponseFuture
public (tower-rs/tower-hyper#47)track down the different active vote plans and their different timelines within the ledger
Before and after finalize operation:
You can seal only transaction with the sufficient amount of witnesses and corresponding types (does order of witnesses matter?)
a vote is always associated to an account so we can track down the stake too. Stake Delegation certificate should be a good example starting point for this
At the moment the unspent is implemented using a BtreeMap
:
struct TransactionUnspents<OutAddress>(BTreeMap<TransactionIndex, Output<OutAddress>>);
whereas it could do with an optimised contiguous implementation with a bitmap and special cases (likely 1 index, 2 indices, 3 indices)
version: newest master
method: assign_account_value
in stake/distribution.rs
file. If we have a DelegationType::Ratio which delegates e.g. Value(100) to non existing 4 pool stakes it is expected that StakeDistribution struct will hold dangling value equal to 100, however it is equal to 800
(this is due to the face that
assign_account_value
mutliply incoming value by 2 and does it 4 times (4 is the number of pools)).
Please run test: dangling_stake_multiplied
in stake/distribution.rs
to observe mentioned behavior (it is possible to uncomment commented assertion to get proper expected value).
This is more like a unit test. We need to check that the ledger, when it applies a new fragment (a new transaction), verify the discrimination.
This is the code in here:
We need to check that:
Relates to #727
Just like Header and Transaction, refactor Content / Fragment and add ContentSlice / FragmentSlice to be cheaper to extract / parse.
If we start with consensus genesis praos in block0, we want to check that the system is in a working state. given that only the one that control the stake, control creation of the block, we need to make sure the system is defined correctly:
for epic input-output-hk/jormungandr#1972
Testing improvements in the chain library
There is a lot of problem that are being reported that could be have
been discovered with better testing of the library.
Testing the blockchain property is an incredibly complex task that may
take a lot of CI time. In order to facilitate writing the testing and
not make the developer life too hard we will split the testing into
different layer of levels.
we need to be able to work on the small properties.
Most of these tests can be property tests (utilising quickcheck
). This is important
as proving these properties if hold independently, the higher composition of these
properties will be easier to test.
These tests are still property tests, but may take a bit longer to execute as they
are testing small scenarios:
theses are slightly more complex tests that may takes some time to execute on the
CI. They intent to test long running properties:
need to restructure the ledger checks / applications to separate some parts, which would give the ability to do more check on fragments ahead of application.
Errors need to splitted in two categories:
Failed
, ...Operations need to separate the stateless checks on a fragment from the stateful checks
Stateless:
Stateful:
strongly related to #7
property test which verifies that changes on the blockchain settings actually
changes the settings when they are voted and adopted.
epic input-output-hk/jormungandr#1972
we need a message and a subscription in order to allow a new class of gossip to be broadcasted through the network.
The content of the message is not specified yet, so a byte array is expected at the moment.
In the module mempack
of chain-core, ReadBuf
looks like a statically lifetime-bound analog of Bytes
from crate bytes
. Switching the Readable
/Writable
traits to working with Bytes
/BytesMut
may enable more flexible zero-copy processing of asynchronously streamable data in the style of tokio-io.
Dependabot couldn't parse the Cargo.toml found at /chain-core/Cargo.toml
.
The error Dependabot encountered was:
Dependabot::DependencyFileNotParseable
We used to run with the log
crate. But we have a requirement for structural logging coming from different end users. log
does not provide this feature yet. For simplicity we will be using slog-scope
crate (and derivative).
Certificate might have different overhead on the chain, and thus might require more fees.
Introduce a certificate trait that allow to define extra fees depending on the certificate type and content, effectively Certificate -> ExtraFee
related to #427
The rusqlite
version we use is quite old and has some problems for Windows builds: @danielSanchezQ reported it prevents fixing input-output-hk/jormungandr#1699, while my standalone experiment with 0.21 and "bundled" worked well with crt-static
.
Update the rusqlite
dependency to the latest version (keep "bundled" on or optionally-default for the time being). There is a use of r2d2_sqlite
backend in chain-storage-sqlite
, which is ironically the more outdated crate, so that needs to be dropped and chain-storage-sqlite-old
renamed as the only surviving storage implementation.
The intent is to optionally be able to bring an old blockchain latest hash as data of the chain. This can be thought as a logical block0.prev
.
One alternative option, that I don't think make sense, is to use the official block0.prev which is right now set to 0, but it's only working if/when we have the same hash size.
Separate the ledger checks for transaction (w or w/ certificate) that have to do with self-validation (making sure the format is ok, and that basic property is enforced correctly), and the context based validation.
e.g.:
X.valid_self() -> Result<(), Error>
X.apply_ledger(ledger: &Ledger) -> Result<Ledger, Error>
this is useful when wanting to make simple verification on transaction without having the Ledger available.
This is needed for input-output-hk/jormungandr#348.
Since we only need the ability to restore a single state (namely the current tip minus some number of blocks), we probably don't need any kind of fancy delta storage (like we had for cardano::ChainState
).
Dependabot couldn't parse the Cargo.toml found at /chain-impl-mockchain/Cargo.toml
.
The error Dependabot encountered was:
Dependabot::DependencyFileNotParseable
add the necessary auth parameter for the vote plan certificate so we can create registration certificate, sign them and propagate them within transactions
leader election through an epoch is on average consistent with the stake distribution.
if a leader as 30% of the total stake, they should be elected 30% of the time;
When using max_limit parameter along with fixed tax, reward mechanism does not take max_limit parameter value into account.
Example:
Given stake pool registration:
StakePool { ...,
rewards: TaxType {
fixed: Value(100),
ratio: Ratio { numerator: 0, denominator: 1 },
max_limit: Some(30)
}, ....
}
Actual reward: 100
Expected reward: 30
chain-libs/chain-impl-mockchain/src/setting.rs
Lines 83 to 85 in e89e48a
and it is not checked from decoding the value from the config param either because we use Milli
:
chain-libs/chain-impl-mockchain/src/config.rs
Lines 328 to 336 in e89e48a
There is an issue in code:
It first increment total and then check if insert is correct which can leads to wrong counter values for participants record. See test:
#[test]
pub fn test_set_new_value_for_existing_stake_pool() {
let stake_pool_id = new_stake_pool_id();
let mut leaders_participation_record = create_log(vec![(stake_pool_id.clone(), 1)]);
assert_eq!(
InsertError::EntryExists,
leaders_participation_record
.set_for(stake_pool_id.clone(), 10)
.err()
.unwrap()
);
assert_eq!(
1,
get_count(&leaders_participation_record, &stake_pool_id).unwrap(),
"wrong count for new stake pool"
);
verify_participants_count(&leaders_participation_record, 1);
//correct expected value: 1
verify_total(&leaders_participation_record, 11);
}
in PR: #223
Now there are two different implementations of bitmaps:
imhamt
(32 bits long)sparse-array
(256 bits long)We need to implement a bitmap that will satisfy different corner-cases (8, 16, ... 256 bits) and be reusable so that we can remove functionality duplication.
We need to be able to check that, for any new transaction applied to the state, the total value remains constant.
This task is a bit more complex as you need to create only valid transaction for a given state of the blockchain. but still possible:
apply the transaction on the blockchain state;
relates to epic #727
The current storage implementation has issues with consistency, including:
Consider adding checks to the database queries to prevent inconsistency in an atomic way.
general improvement to signing
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.