摘要:在主網(wǎng)上玩耍的小伙伴們肯定遇到過區(qū)塊回滾導(dǎo)致自己的交易沒有上鏈。這種情況讓有些人誤以為區(qū)塊回滾會(huì)丟棄交易。其實(shí)區(qū)塊回滾并不是導(dǎo)致交易沒上鏈的主要原因,主要原因是交易過期了才導(dǎo)致交易被丟棄。源碼解析我們來看看區(qū)塊生產(chǎn)時(shí)是如何丟棄過期交易的。
????在主網(wǎng)上玩耍的小伙伴們肯定遇到過區(qū)塊回滾導(dǎo)致自己的交易沒有上鏈。這種情況讓有些人誤以為區(qū)塊回滾會(huì)丟棄交易。 其實(shí)區(qū)塊回滾并不是導(dǎo)致交易沒上鏈的主要原因, 主要原因是交易過期了才導(dǎo)致交易被丟棄。
流程描述:每個(gè)交易是會(huì)被廣播到全網(wǎng)每個(gè)節(jié)點(diǎn)上面的( ps: 當(dāng)然傳播過程中過期的話,當(dāng)我沒說哈 ),假如出塊節(jié)點(diǎn) A 打包了 trx a, 但此時(shí)出塊節(jié)點(diǎn) B 沒接受到 A 的打包塊,他也開始打包了,那么他也包含了該 trx a 并會(huì)將他打包( ps: 當(dāng)然也有例外情況,那就是 出塊節(jié)點(diǎn) B 接收到 trx a 時(shí),他就過期了,所以還沒打包就丟棄他,或者還沒傳遞到出塊節(jié)點(diǎn) B, 但會(huì)抵達(dá)下個(gè)節(jié)點(diǎn) C D E, 但情況相似,就不另外說明了 )。但如果 a 的過期時(shí)間設(shè)置過短,導(dǎo)致出塊節(jié)點(diǎn) B 打包時(shí)發(fā)現(xiàn)他過期了,就會(huì)丟棄他。 這便是交易沒上鏈的原因。源碼解析:
我們來看看區(qū)塊生產(chǎn)時(shí)是如何丟棄過期交易的。區(qū)塊生產(chǎn)的流程 區(qū)塊的分叉處理可以看下我之前的文章。這里生產(chǎn)區(qū)塊以及回滾的細(xì)節(jié)就不贅述了。
區(qū)塊打包時(shí),會(huì)將 pending block 里已經(jīng)執(zhí)行成功了的 trx 另外存起來, 并初始化 pending block。 等到打包的時(shí)候會(huì)再去執(zhí)行一次這些 trx , 咦,為什么要重新執(zhí)行一遍浪費(fèi)資源,因?yàn)檫@些 trx 都是在區(qū)塊打包之前執(zhí)行的,鬼知道過期了沒有 =,=。
以下是交易被殘忍丟棄的過程:
// controller.cpp
// 將 pending block 的 trx 保存到 unapplied_transaction
void abort_block() {
if( pending ) {
if ( read_mode == db_read_mode::SPECULATIVE ) { for( const auto& t : pending->_pending_block_state->trxs ) unapplied_transactions[t->signed_id] = t; } pending.reset();
}
}
// producer_plugin.cpp
producer_plugin_impl::start_block_result producer_plugin_impl::start_block(bool &last_block) {
// ...
try {
// ... // 將 pending block 里面的 trx 保存了 unapplied_transaction chain.abort_block(); // 初始化 pending block chain.start_block(block_time, blocks_to_confirm);
} FC_LOG_AND_DROP();
const auto& pbs = chain.pending_block_state();
if (pbs) {
// ... // _persistent_transactions 是指通過該節(jié)點(diǎn)的 http 端口 push_transaction 推送過來的 trx // remove all persisted transactions that have now expired auto& persisted_by_id = _persistent_transactions.get(); auto& persisted_by_expiry = _persistent_transactions.get (); if (!persisted_by_expiry.empty()) { int num_expired_persistent = 0; int orig_count = _persistent_transactions.size(); // 丟棄過期交易 while(!persisted_by_expiry.empty() && persisted_by_expiry.begin()->expiry <= pbs->header.timestamp.to_time_point()) { auto const& txid = persisted_by_expiry.begin()->trx_id; if (_pending_block_mode == pending_block_mode::producing) { fc_dlog(_trx_trace_log, "[TRX_TRACE] Block ${block_num} for producer ${prod} is EXPIRING PERSISTED tx: ${txid}", ("block_num", chain.head_block_num() + 1) ("prod", chain.pending_block_state()->header.producer) ("txid", txid)); } else { fc_dlog(_trx_trace_log, "[TRX_TRACE] Speculative execution is EXPIRING PERSISTED tx: ${txid}", ("txid", txid)); } persisted_by_expiry.erase(persisted_by_expiry.begin()); num_expired_persistent++; } fc_dlog(_log, "Processed ${n} persisted transactions, Expired ${expired}", ("n", orig_count) ("expired", num_expired_persistent)); } try { size_t orig_pending_txn_size = _pending_incoming_transactions.size(); // Processing unapplied transactions... // 當(dāng)節(jié)點(diǎn)不是 出塊節(jié)點(diǎn)并且 也沒有通過該節(jié)點(diǎn)推送的 trx, 則 unapplied_transaction 無意義 // 因?yàn)槟悴恍枰虬鼌^(qū)塊, 也沒有 trx 需要廣播出去。 if (_producers.empty() && persisted_by_id.empty()) { // if this node can never produce and has no persisted transactions, // there is no need for unapplied transactions they can be dropped chain.drop_all_unapplied_transactions(); } else { std::vector apply_trxs; { // derive appliable transactions from unapplied_transactions and drop droppable transactions auto unapplied_trxs = chain.get_unapplied_transactions(); apply_trxs.reserve(unapplied_trxs.size()); auto calculate_transaction_category = [&](const transaction_metadata_ptr& trx) { if (trx->packed_trx.expiration() < pbs->header.timestamp.to_time_point()) { return tx_category::EXPIRED; } else if (persisted_by_id.find(trx->id) != persisted_by_id.end()) { return tx_category::PERSISTED; } else { return tx_category::UNEXPIRED_UNPERSISTED; } }; // 將沒過期的放進(jìn) apply_trxs, 過期的丟棄掉。 for (auto& trx: unapplied_trxs) { auto category = calculate_transaction_category(trx); if (category == tx_category::EXPIRED || (category == tx_category::UNEXPIRED_UNPERSISTED && _producers.empty())) { if (!_producers.empty()) { fc_dlog(_trx_trace_log, "[TRX_TRACE] Node with producers configured is dropping an EXPIRED transaction that was PREVIOUSLY ACCEPTED : ${txid}", ("txid", trx->id)); } chain.drop_unapplied_transaction(trx); } else if (category == tx_category::PERSISTED || (category == tx_category::UNEXPIRED_UNPERSISTED && _pending_block_mode == pending_block_mode::producing)) { apply_trxs.emplace_back(std::move(trx)); } } } if (!apply_trxs.empty()) { // 執(zhí)行 trx, 成功的 emplace_back 進(jìn) pending block } } // ... // 執(zhí)行 deffered transaction // 和執(zhí)行 初始化 pending block 時(shí)推送進(jìn)來的 transcation ( 因?yàn)槌跏蓟瘯r(shí),pending block 不能存 trx, 所以先另外存起來)
}
return start_block_result::failed;
}
回滾并不會(huì)丟棄 trx, 只會(huì)導(dǎo)致 trx 延后打包,以致于 trx 可能過期被丟棄。
設(shè)置過期時(shí)間時(shí),時(shí)間跨度應(yīng)該足夠 2 個(gè) BP 出完塊,這樣即使 B 沒接收到 A 的區(qū)塊,但 trx 不會(huì)因?yàn)檫^期而被 B 丟棄,當(dāng)然還要大致估算你的 trx 廣播到出塊節(jié)點(diǎn)的時(shí)間。
有任何疑問或者想交流的朋友可以加 EOS LIVE 小助手,備注 eos開發(fā)者拉您進(jìn) EOS LIVE DAPP 開發(fā)者社區(qū)微信群哦。
圖片描述
?原文鏈接:https://eos.live/detail/18931
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/24488.html
摘要:在每個(gè)交易中,我們都會(huì)看到和這個(gè)參數(shù)有什么作用呢。先講下它的大致作用,再來對(duì)代碼進(jìn)行分析。這是白皮書對(duì)這個(gè)參數(shù)的作用描述他是用來防止有不包含區(qū)塊引用的交易被重放到某個(gè)分叉上,這樣能避免不是該分叉的區(qū)塊被添加到該分叉。 在每個(gè) trx 交易中,我們都會(huì)看到 ref_block_num 和 ref_block_prefix, 這2個(gè)參數(shù)有什么作用呢。 先講下它的大致作用,再來對(duì)代碼進(jìn)行分析...
摘要:區(qū)塊多線程簽名改動(dòng)同步區(qū)塊時(shí)進(jìn)行多線程簽名,過程中依然是單線程簽名。代碼解析塊簽名因?yàn)椴贿m用多線程簽名,所以依舊沿用之前的簽名代碼,而同步則使用了新的部分。當(dāng)大家比較關(guān)注的使用并沒有得到改善,因?yàn)槎嗑€程簽名無法應(yīng)該在生產(chǎn)區(qū)塊上。 昨天早上,EOS 1.5.0 release 版本發(fā)布了。這次比較大改動(dòng)點(diǎn)是在多線程簽名上面。它將同步區(qū)塊時(shí)的 block 簽名驗(yàn)證和 trx 簽名驗(yàn)證都使用...
摘要:穩(wěn)定幣的上線年月日,發(fā)布了穩(wěn)定幣,并且成功通過了社區(qū)多簽。年月日,的穩(wěn)定幣正式上線。年月日,六大個(gè)稅抵扣社會(huì)保險(xiǎn)費(fèi)由稅務(wù)部門統(tǒng)一征收等一批新規(guī)正式實(shí)施。本次的攻擊為針對(duì)項(xiàng)目方的重放攻擊。 FIBOS 穩(wěn)定幣的上線 2018年12月21日,F(xiàn)IBOS 發(fā)布了穩(wěn)定幣—— FOD,并且成功通過了社區(qū)多簽。 2018年12月28日, FIBOS 的穩(wěn)定幣 FOD 正式上線。 早在2018年9月...
摘要:穩(wěn)定幣的上線年月日,發(fā)布了穩(wěn)定幣,并且成功通過了社區(qū)多簽。年月日,的穩(wěn)定幣正式上線。年月日,六大個(gè)稅抵扣社會(huì)保險(xiǎn)費(fèi)由稅務(wù)部門統(tǒng)一征收等一批新規(guī)正式實(shí)施。本次的攻擊為針對(duì)項(xiàng)目方的重放攻擊。 FIBOS 穩(wěn)定幣的上線 2018年12月21日,F(xiàn)IBOS 發(fā)布了穩(wěn)定幣—— FOD,并且成功通過了社區(qū)多簽。 2018年12月28日, FIBOS 的穩(wěn)定幣 FOD 正式上線。 早在2018年9月...
摘要:第一類模式是在公鏈項(xiàng)目中運(yùn)用的最廣泛應(yīng)用的共識(shí)算法,比特幣長達(dá)年的運(yùn)行已充分證明的安全性與穩(wěn)定性。此時(shí)當(dāng)前區(qū)塊已是合法區(qū)塊但是未獲得最終確認(rèn),類似于比特幣未獲得個(gè)塊確認(rèn)存在回滾的可能性。 showImg(https://segmentfault.com/img/bVbtamO?w=1000&h=600); 共識(shí)算法是分布式系統(tǒng)保證節(jié)點(diǎn)數(shù)據(jù)狀態(tài)一致性的方法,在區(qū)塊鏈的共識(shí)算法分POW(工...
閱讀 1994·2021-11-15 18:09
閱讀 889·2021-09-06 15:13
閱讀 2636·2021-08-23 09:43
閱讀 2016·2019-08-30 15:54
閱讀 2208·2019-08-30 13:56
閱讀 2476·2019-08-26 11:31
閱讀 3070·2019-08-26 10:56
閱讀 685·2019-08-26 10:28