Andreas Fackler
Andreas Fackler
## Motivation The current `Committee` implementation is a bit complicated, and sometimes sets the quorum threshold higher than necessary. ## Proposal The assumption is that $$N \geq 3 f +...
`ChainClient::execute_operations` currently retries the operations at the next block height if a conflicting block was committed. This isn't always desirable and shouldn't be the default behavior.
`linera net up --with-faucet` seems to use the admin wallet for the faucet, so the `export` statements it prints to set the wallet directory are not useful: The wallet is...
If a confirmed block sending a message has been seen in a node (client or validator), and the message put into the recipient chain's inbox, we currently call it "added"...
The word "committee" only refers to the set of validators, but an epoch now has more information than that, like the resource policy. Also, the same committee can be used...
`chain_client.listen()` will synchronize the chain, but does not update the wallet if new blocks were processed. (Edit: On another chain it did! Anyway, it doesn't seem to always do it.)
(From [this comment](https://github.com/linera-io/linera-protocol/pull/4706#discussion_r2395203847).) We have: - `synchronize_chain_state(chain_id)` which internally loads the committee and then synchronizes the state - `synchronize_chain_state_from_committee(committee)` which requires committee but internally knows which chain to synchronize -...
There are different places in the updater and client where we handle errors returned by remote nodes, e.g.: * missing blobs published by the proposal, * missing blobs used in...