10

Until BFT messages are deployed and working, the DPOS side of BFT-DPOS will reach finality for a transaction 180 seconds after it is included in a block. This is assuming a nominal network conditions with 21 producers. The math to arrive at this number is that, each block must be "pre-committed" to by 2/3 + 1 producers in order to be eligible for "...


3

Last irreversible block (LIB) is the way of providing BFT finality assuming at least 2/3+1 honest producers. However, a single confirmation from a BP is not sufficient proof to contribute to making an irreversible block--this would mean that when the last of the 2/3+1 BPs signs the block, it's immediately irreversible. However, by the time the other (honest) ...


2

Overview If a transaction is introduced in a block that never achieves 2/3+1 confirmations, it means there's likely a fork where at least 1/3 of the BPs are building blocks on. In this case, the blockchain is forked, and the fork with more BPs will be faster and thus will become the longest chain, where honest BPs will build on. Neither of the forks will ...


2

According to the whitepaper: Transaction Confirmation Typical DPOS blockchains have 100% block producer participation. A transaction can be considered confirmed with 99.9% certainty after an average of 0.25 seconds from time of broadcast. In addition to DPOS, EOS.IO adds asynchronous Byzantine Fault Tolerance (aBFT) for faster achievement ...


2

You must wait for a block height to be lower than the current Last Irreversible Block (also known as LIB) to be considered irreversible. With the quick speed of the network, it is common to see microforks that occur - often when ProducerB starts producing its schedule off of Block 11 of ProducerA's round. This can happen due to latency conditions because of ...


1

Use /v1/chain/get_info to know the last_irreversible_block_num


1

I would look into EOS Rio's Hyperion Solution for producing a light full history node. This could help achieve your goal of reducing the node's storage requirements as well as decreasing the syncing time. From their announcement: Changing format and cutting data redundancies reduces database size in about 85%, from almost 5 Tb to approximately 650 Gb. ...


1

When you do a transaction you get the expiration time of the transaction along with the tx hash other than few other parameters. The expiration time is the time till which the tx is valid.If the tx gets included in the blockchain in block x after it is broadcasted ( this can be checked by using the command cleos get transaction txid ) , then . within the ...


1

From the wiki: https://github.com/EOSIO/eos/wiki/Smart-Contract#transaction-confirmation On completion of the transaction, a transaction receipt is generated. Receiving a transaction hash does not mean that the transaction has been confirmed, it only means that the node accepted it without error, which also means that there is a high probability other ...


1

According to the whitepaper: Transaction Confirmation Typical DPOS blockchains have 100% block producer participation. A transaction can be considered confirmed with 99.9% certainty after an average of 0.25 seconds from time of broadcast. In addition to DPOS, EOS.IO adds asynchronous Byzantine Fault Tolerance (aBFT) for faster achievement ...


1

there's a write-up on how exchanges should deal with deposits and withdrawals on the eos blockchain. It deals with irreversible blocks, might be useful: https://developers.eos.io/eosio-cpp/docs/exchange-deposit-withdraw


Only top voted, non community-wiki answers of a minimum length are eligible