* Update proposal scenario (#692) * add new certs to FragmentFactory enhance controller with new methods for update proposals * add new test * add different signer for proposal update or vote
let fragment = fragment_factory.update_proposal(
testledger.date().next_epoch(),
&leader,
update_proposal_data.proposal.clone(),
&leader,
update_proposal_data.proposal.clone().into(),
);
leader.confirm_transaction();
// apply votes
for vote in update_proposal_data.gen_votes(fragment.id()) {
let fragment = fragment_factory.update_vote(testledger.date().next_epoch(), &leader, vote);
let fragment =
fragment_factory.update_vote(testledger.date().next_epoch(), &leader, &leader, vote);
testledger
.apply_fragment(&fragment, BlockDate::first().next_epoch())
.unwrap();
key::EitherEd25519SecretKey,
testing::builders::make_witness_with_lane,
testing::data::LeaderPair,
testing::data::LeaderPair,
tokens::name::TokenName,
transaction::{Input, Output, TransactionAuthData, Witness},
utxo::Entry,
&self,
valid_until: BlockDate,
owner: &Wallet,
signer: &Wallet,
update_proposal: UpdateProposal,
) -> Fragment {
self.transaction_with_cert(valid_until, Some(owner), &update_proposal.into())
TestTxCertBuilder::new(self.block0_hash, self.fee).make_transaction_different_signers(
valid_until,
owner,
vec![signer],
&update_proposal.into(),
)
}
pub fn update_vote(
&self,
valid_until: BlockDate,
owner: &Wallet,
signer: &Wallet,
update_vote: UpdateVote,
) -> Fragment {
self.transaction_with_cert(valid_until, Some(owner), &update_vote.into())
}
pub fn mint_token(
&self,
valid_until: BlockDate,
owner: &Wallet,
min_token: MintToken,
) -> Fragment {
self.transaction_with_cert(valid_until, Some(owner), &min_token.into())
TestTxCertBuilder::new(self.block0_hash, self.fee).make_transaction_different_signers(
valid_until,
owner,
vec![signer],
&update_vote.into(),
)
}
fn transaction_with_cert<'a>(
* I removed an outdated comment * I renamed datum to datum_option (since it can be a hash or a datum)
Other small changes include: * Added a trace event `TDBInitialisingFromLMDBDone`. * Initialisation from an existing LMDB database does not rely on the default `LMDBLimits` anymore, and is passed a limits argument instead. TODO: We should decide whether we want to hardcode these limits to a a substantially large one, or possibly we could link these limits to a versioning number?
add cwbtc
attempt implementation
Other small changes include: * Added a trace event `TDBInitialisingFromLMDBDone`. * Initialisation from an existing LMDB database does not rely on the default `LMDBLimits` anymore, and is passed a limits argument instead. TODO: We should decide whether we want to hardcode these limits to a a substantially large one, or possibly we could link these limits to a versioning number?
![iohk-bors[bot]](https://avatars.githubusercontent.com/in/17473?v=4&s=80)
Updated crypto exchange rates chapter. I tried my best to address @rdlrt concerns. I would like to add that English is just my 3rd language, so I hope it is not too bad.
Previously, the sequence number of the database is written to disk as part of the on-disk database settings on every flush/write. Conceptually however, the settings of a database should not change on every flush or write. Instead, we make a dinstinction between on-disk database "settings" and "state", where the state can be updated in every write/flush, but the settings should generally be left untouched after database initialisation or node start-up.
Fixes #217.
This works because (a) JavaScript is ultimately single-threaded, (b) there's no execution preemption happening between a 'send' and a 'wait'.