{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":245060662,"defaultBranch":"master","name":"ronin","ownerLogin":"axieinfinity","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2020-03-05T03:33:51.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/36193737?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1726740740.0","currentOid":""},"activityList":{"items":[{"before":"f2ae2f8074574e3d387d2d0e584f142d6c95620b","after":"75cad3de20513acb6f4bd7c2882edc195a36a2c1","ref":"refs/heads/master","pushedAt":"2024-09-20T02:58:23.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"minh-bq","name":null,"path":"/minh-bq","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/97180373?s=80&v=4"},"commit":{"message":"core/txpool/blobpool: avoid possible zero index panic (#30430) (#579)\n\ncommit https://github.com/ethereum/go-ethereum/commit/0dd7e82c0aef3c27303b4a7b30016790dda949d4.\r\n\r\nThis situation(`len(txs) == 0`) rarely occurs, but if it does, it will\r\npanic.\r\n\r\n---------\r\n\r\nCo-authored-by: maskpp \r\nCo-authored-by: Martin HS ","shortMessageHtmlLink":"core/txpool/blobpool: avoid possible zero index panic (#30430) (#579)"}},{"before":"a25b351f400f24428102cf8fdee106f5e59e61ed","after":"aaa7b87a59067a07c87b4ff3983b8a8daaa79ae8","ref":"refs/heads/implement-abstract-node-scheme","pushedAt":"2024-09-19T10:19:37.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"core,eth,tests,trie: abstract node scheme, and contruct database\ninterface instead of keyvalue for supporting storing diff reverse data\nin ancient","shortMessageHtmlLink":"core,eth,tests,trie: abstract node scheme, and contruct database"}},{"before":"be08ccd16afb45d3a61202152288b55de9862712","after":null,"ref":"refs/heads/implement-freezer-tail-deletion","pushedAt":"2024-09-19T10:12:20.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"}},{"before":"a16a5d08bd011ef927a12881105b84250ef8843e","after":"ca6e07fb7e1340b7aef0900afa6f14cf4491548a","ref":"refs/heads/path-base-implementing","pushedAt":"2024-09-19T09:11:34.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"rawdb,ethdb,eth: implement freezer tail deletion and use atomic reference commit 538a868 (#577)\n\nfix up","shortMessageHtmlLink":"rawdb,ethdb,eth: implement freezer tail deletion and use atomic refer…"}},{"before":null,"after":"a25b351f400f24428102cf8fdee106f5e59e61ed","ref":"refs/heads/implement-abstract-node-scheme","pushedAt":"2024-09-18T09:45:42.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"core,eth,tests,trie: abstract node scheme, and contruct database\ninterface instead of keyvalue for supporting storing diff reverse data\nin ancient","shortMessageHtmlLink":"core,eth,tests,trie: abstract node scheme, and contruct database"}},{"before":"d88adc90dca2755066a1497dd06d799f6152ceb9","after":"be08ccd16afb45d3a61202152288b55de9862712","ref":"refs/heads/implement-freezer-tail-deletion","pushedAt":"2024-09-18T08:50:35.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"rawdb,ethdb,eth: implement freezer tail deletion and use atomic reference commit 538a868\n\nfix up","shortMessageHtmlLink":"rawdb,ethdb,eth: implement freezer tail deletion and use atomic refer…"}},{"before":"06b47c69031e727104f2d450206b2a0f216cb8b3","after":"d88adc90dca2755066a1497dd06d799f6152ceb9","ref":"refs/heads/implement-freezer-tail-deletion","pushedAt":"2024-09-18T07:05:10.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"rawdb,ethdb,eth: implement freezer tail deletion and use atomic reference commit 538a868","shortMessageHtmlLink":"rawdb,ethdb,eth: implement freezer tail deletion and use atomic refer…"}},{"before":"c340b27aea5257b9fe714c26f2c0fb9c51643b3c","after":"06b47c69031e727104f2d450206b2a0f216cb8b3","ref":"refs/heads/implement-freezer-tail-deletion","pushedAt":"2024-09-18T04:57:41.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"rawdb: resolve conflict","shortMessageHtmlLink":"rawdb: resolve conflict"}},{"before":"df9fed822367894109454b4d03e1e6bf3329d3a8","after":null,"ref":"refs/heads/make-db-inspector-for-extending-multiple-ancient-stores","pushedAt":"2024-09-18T04:31:15.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"}},{"before":"ca1f046fae8db8d471ca6cceb6267ef2ed9aedf6","after":"a16a5d08bd011ef927a12881105b84250ef8843e","ref":"refs/heads/path-base-implementing","pushedAt":"2024-09-18T04:30:31.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"Make db inspector for extending multiple ancient stores (#574)\n\n* core: add blockchain test for failing create/destroy-case\r\n\r\n* core,state: some refactors\r\n\r\n* core/rawdb: refactor db inspector for extending multiple ancient store","shortMessageHtmlLink":"Make db inspector for extending multiple ancient stores (#574)"}},{"before":"883442590e60b488afdeec9f11c39569e6e29a0e","after":"c340b27aea5257b9fe714c26f2c0fb9c51643b3c","ref":"refs/heads/implement-freezer-tail-deletion","pushedAt":"2024-09-17T16:43:16.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"rawdb,ethdb,eth: implement freezer tail deletion and use atomic reference commit 538a868","shortMessageHtmlLink":"rawdb,ethdb,eth: implement freezer tail deletion and use atomic refer…"}},{"before":"f549c2d3852169debcdfedc97d9639c5c73af80e","after":"883442590e60b488afdeec9f11c39569e6e29a0e","ref":"refs/heads/implement-freezer-tail-deletion","pushedAt":"2024-09-17T12:19:33.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"rawdb,ethdb,eth: implement freezer tail deletion and use atomic reference commit 538a868","shortMessageHtmlLink":"rawdb,ethdb,eth: implement freezer tail deletion and use atomic refer…"}},{"before":null,"after":"f549c2d3852169debcdfedc97d9639c5c73af80e","ref":"refs/heads/implement-freezer-tail-deletion","pushedAt":"2024-09-17T10:38:27.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"rawdb,ethdb,eth: implement freezer tail deletion and use atomic reference commit 538a868","shortMessageHtmlLink":"rawdb,ethdb,eth: implement freezer tail deletion and use atomic refer…"}},{"before":"5cff5c84784c876f8d3a8f7b6e88163128e1e632","after":"df9fed822367894109454b4d03e1e6bf3329d3a8","ref":"refs/heads/make-db-inspector-for-extending-multiple-ancient-stores","pushedAt":"2024-09-17T05:07:10.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"core/rawdb: refactor db inspector for extending multiple ancient store","shortMessageHtmlLink":"core/rawdb: refactor db inspector for extending multiple ancient store"}},{"before":"3cb37d62c95c0a91480ee145a6d1551c4c054475","after":"ca1f046fae8db8d471ca6cceb6267ef2ed9aedf6","ref":"refs/heads/path-base-implementing","pushedAt":"2024-09-17T05:01:39.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"all: move genesis init to blockchain (#570)\n\n* all: move genesis initialization to blockchain\n\n* all: fix test","shortMessageHtmlLink":"all: move genesis init to blockchain (#570)"}},{"before":"55228df50484cdd051d11dd5b4e6dab7302e13ae","after":"5cff5c84784c876f8d3a8f7b6e88163128e1e632","ref":"refs/heads/make-db-inspector-for-extending-multiple-ancient-stores","pushedAt":"2024-09-17T04:45:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"core/rawdb: refactor db inspector for extending multiple ancient store","shortMessageHtmlLink":"core/rawdb: refactor db inspector for extending multiple ancient store"}},{"before":"0f27ff6c34ab690a8a68e755ae08833b722c3c20","after":"3cb37d62c95c0a91480ee145a6d1551c4c054475","ref":"refs/heads/path-base-implementing","pushedAt":"2024-09-17T04:42:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"all: move genesis init to blockchain (#570)\n\n* all: move genesis initialization to blockchain\n\n* all: fix test","shortMessageHtmlLink":"all: move genesis init to blockchain (#570)"}},{"before":"efbc4f717a702527035a4532d4a7da25d0f006da","after":"f2ae2f8074574e3d387d2d0e584f142d6c95620b","ref":"refs/heads/master","pushedAt":"2024-09-17T04:17:23.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"minh-bq","name":null,"path":"/minh-bq","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/97180373?s=80&v=4"},"commit":{"message":"core/rawdb: fix double-lock causing hang (#24189) (#575)\n\ncommit https://github.com/ethereum/go-ethereum/commit/66a908c5e87a4f38c0507ae2c7e53b242deb7128.\r\n\r\nRecursive read-locking is prohibited in RWMutex which can lead to deadlock.\r\nReadCanonicalHash internally calls ReadAncients which cause recursive\r\nread-locking. This commit reads the block directly from leveldb/pebbledb in case\r\nblock is not in ancient without using helper function ReadCanonicalHash.\r\n\r\nCo-authored-by: Martin Holst Swende \r\nCo-authored-by: Felix Lange ","shortMessageHtmlLink":"core/rawdb: fix double-lock causing hang (#24189) (#575)"}},{"before":"3132f210564bcb2c0d92043b27c8ddea792797b3","after":null,"ref":"refs/heads/dependabot/go_modules/github.com/docker/docker-25.0.6incompatible","pushedAt":"2024-09-17T04:00:15.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"dependabot[bot]","name":null,"path":"/apps/dependabot","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/29110?s=80&v=4"}},{"before":"47351b1d4023ba771b1e226eabedefc19d50e9c3","after":"55228df50484cdd051d11dd5b4e6dab7302e13ae","ref":"refs/heads/make-db-inspector-for-extending-multiple-ancient-stores","pushedAt":"2024-09-16T16:43:54.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"core/rawdb: refactor db inspector for extending multiple ancient store","shortMessageHtmlLink":"core/rawdb: refactor db inspector for extending multiple ancient store"}},{"before":null,"after":"47351b1d4023ba771b1e226eabedefc19d50e9c3","ref":"refs/heads/make-db-inspector-for-extending-multiple-ancient-stores","pushedAt":"2024-09-16T16:16:15.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"core/rawdb: refactor db inspector for extending multiple ancient store","shortMessageHtmlLink":"core/rawdb: refactor db inspector for extending multiple ancient store"}},{"before":null,"after":"3132f210564bcb2c0d92043b27c8ddea792797b3","ref":"refs/heads/dependabot/go_modules/github.com/docker/docker-25.0.6incompatible","pushedAt":"2024-09-16T10:15:32.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"dependabot[bot]","name":null,"path":"/apps/dependabot","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/29110?s=80&v=4"},"commit":{"message":"build(deps): bump github.com/docker/docker\n\nBumps [github.com/docker/docker](https://github.com/docker/docker) from 1.4.2-0.20180625184442-8e610b2b55bf to 25.0.6+incompatible.\n- [Release notes](https://github.com/docker/docker/releases)\n- [Commits](https://github.com/docker/docker/commits/v25.0.6)\n\n---\nupdated-dependencies:\n- dependency-name: github.com/docker/docker\n dependency-type: direct:production\n...\n\nSigned-off-by: dependabot[bot] ","shortMessageHtmlLink":"build(deps): bump github.com/docker/docker"}},{"before":"0eae9519d2f72a12fa3e7ca5846979a5ef1c0d80","after":null,"ref":"refs/heads/blob-transaction-v2","pushedAt":"2024-09-16T10:13:48.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"minh-bq","name":null,"path":"/minh-bq","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/97180373?s=80&v=4"}},{"before":"fd7a298a38e87686f74ab08e45a8dc4be647fb76","after":"efbc4f717a702527035a4532d4a7da25d0f006da","ref":"refs/heads/master","pushedAt":"2024-09-16T10:13:42.000Z","pushType":"pr_merge","commitsCount":63,"pusher":{"login":"minh-bq","name":null,"path":"/minh-bq","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/97180373?s=80&v=4"},"commit":{"message":"eth: make transaction propagation paths in the network deterministic (#29034)\n\ncommit https://github.com/ethereum/go-ethereum/commit/0b1438c3df5da5551e89dddc683d65f4d48ad3d6.\n\nGeth currently propagates new transactions by sending them in full to\nsqrt(peers) and announcing their hashes to the rest of the peers. The exceptions\nare peers that already are known to have the transactions (neither is done for\nthem) and large/blob transactions (which are always announced). For this PR's\nscope, we don't care about the special cases, only the normal new transactions.\n\nThe rationale behind the broadcast/announce split is that broadcasting to\neveryone in full would be very wasteful, as everyone would in essence receive\nthe same transactions from all their peers. Announcing it to everyone on the\nother hand would minimize traffic, but would maximise distribution latency as\neveryone would need to explicitly ask for an announced transaction. Depending on\nwhatever timeout clients would use, this could lead to multi-second delays in a\nsingle transaction's propagation time. Broadcasting to a few peers and\nannouncing to everyone else ensures that the transaction ripples through well\nconnected peers very fast and any degenerate part of the network is covered by\nannouncements. The ideal ratio of the split between broadcast and announce is\nthe topic of a different discussion.\n\nThe interesting tidbit for this PR is that the split between broadcast and\nannounce is currently done at random in Geth. We calculate that a new\ntransaction needs to be sent in full to N peers out of M, and just pick them at\nrandom. This randomness is very much desired as it ensures that the network load\ncaused by transactions is evenly distributed across all connections. As long as\ntransactions are arriving at a steady rate from different accounts, this\nmechanism works well. It doesn't matter who sends what, we randomly pass it\nacross the network and everyone will receive it one way or another.\n\nA problem arises however when there is a burst of transactions from the same\naccount (whether insta-sending K transactions or individually in very quick\nsuccession). The problem is that evaluating whom to send in full and whom to\nannounce by hash is evaluated randomly, independently across transactions.\n\nWith K transactions arriving simultaneously from the same account, those would\nget randomly broadcast across our peer set. With a probability of 1, all peers\nwill receive a sequence of nonce-gapped transactions, the gaps being announced\nonly. This is a double issue: nodes will only forward executable transactions,\nso whenever a peer encounters a nonce gap, propagation will be choked from that\npoint onward. Even though the gaps are announced, those will be received delayed\n(whether filled by someone else or needing explicit retrieval), time by which\nthe gapped transactions might already be dropped. The issue is even worse for K\ntransactions arriving individually in quick succession (say 50ms apart). There\nthe exact same problem arises, but we can't even try to group transactions by\naccount because we don't know what we've broadcast before and what future\ntransactions will arrive. Tracking broadcast targets across time is a non\ntrivial complexity. Geth's current solution to this problem is the transaction\npool. In the \"legacy\" pool, we track two sets of transactions: the pending set,\ncontaining all the executable transactions (no nonce gaps) and the queued set,\ncontaining a mixed bag of everything that's missing a nonce. As time passes and\ngaps are filled in, we move queued transactions to pending transactions. Whilst\nin theory workable, in practice this constant shuffling makes the pool extremely\nbrittle and easy to attack. The only way to simplify the pool and make it both\nmore robust and possibly have a larger capacity is to somehow get rid of this 2\nset complexity. For that to happen, we need to fix transaction propagation\nsomehow to get rid of nonce gaps altogether. Whilst it might be \"unfeasible\" to\nmake propagation 100% accurate and thus completely remove the pool's complexity;\nif we could make propagation almost-perfect, we could probably also very\nagressively simplify the txpool to only track a minimal subset of gaps for\n\"flukes\".\n\nCan we fix transaction propagation though? At least making it\n\"approximately-correct\". This PR is an attempt at saying Yes to that question.\nWhat we would like to achieve is to keep the current performance of transaction\npropagation (wrt bandwidth and latency), but avoid the nonce-gap-generation\nissue. The only way to do that is to ensure that if a tx is broadcast in full to\na peer, all subsequent txs from the same account are broadcast in full. If on\nthe other hand the tx is announced, all subsequent transactions are announced.\nThe naive solution of tracking what we sent to who is a can of worms nobody\nwants to open (especially when we would like this mechanism to work across a\nlonger time frame).\n\nThe solution this PR proposes, is to \"define\" a \"semi-stable\" transaction\nbroadcast/announce topology, where every node \"knows\" to whom they should\nbroadcast and to whom they should announce, without having a complete view of\nthe network or the transaction pool. It's ok if this \"topology\" is not\ncompletely stable, but it should be stable \"enough\" to capture\nsemi-instantaneous bursts and keep then on the same propagation path wrt\nbroadcasts/announce.\n\nInstead of picking sqrt peers at random to broadcast to; or instead of tracking\nto whom we've broadcasted before; the PR proposes to hash our own ID with a\npeer's ID and with the tx sender and use that checksum to select sqrt(peers) to\nbroadcast to. The elegance of this algorithm is that as long as I have a\nrelatively stable number of peers, the same peers will be selected over and over\nand over again for broadcasting, independent of what other peers are connected;\nand with exactly 0 state tracking. If enough peers join/leave to change the\nsqrt(peer) value, the topology will change, but apart from a startup wonkyness,\nthe connections and pathways will be stable most of the time.\n\nThe immediate upside is that nonce gaps should almost completely disappear (the\nmore other clients also chose to implement this (or any other stable topology,\ndoesn't have to be the same), the better the stability). With very minimised\nnonce gaps, we would be able to drastically simplify the txpool gapped tx\nhandling since that would be the exception, not the general rule. Also,\nimportant to highlight, this change is essentially free from all perspectives:\ncomputationally 0, complexity wise 0, effort wise to add to Geth or any other\nclient 0.","shortMessageHtmlLink":"eth: make transaction propagation paths in the network deterministic …"}},{"before":"ace591cf9899393c5194d052cc1379886ce5da8d","after":"0eae9519d2f72a12fa3e7ca5846979a5ef1c0d80","ref":"refs/heads/blob-transaction-v2","pushedAt":"2024-09-16T09:20:11.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"minh-bq","name":null,"path":"/minh-bq","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/97180373?s=80&v=4"},"commit":{"message":"eth: make transaction propagation paths in the network deterministic (#29034)\n\ncommit https://github.com/ethereum/go-ethereum/commit/0b1438c3df5da5551e89dddc683d65f4d48ad3d6.\n\nGeth currently propagates new transactions by sending them in full to\nsqrt(peers) and announcing their hashes to the rest of the peers. The exceptions\nare peers that already are known to have the transactions (neither is done for\nthem) and large/blob transactions (which are always announced). For this PR's\nscope, we don't care about the special cases, only the normal new transactions.\n\nThe rationale behind the broadcast/announce split is that broadcasting to\neveryone in full would be very wasteful, as everyone would in essence receive\nthe same transactions from all their peers. Announcing it to everyone on the\nother hand would minimize traffic, but would maximise distribution latency as\neveryone would need to explicitly ask for an announced transaction. Depending on\nwhatever timeout clients would use, this could lead to multi-second delays in a\nsingle transaction's propagation time. Broadcasting to a few peers and\nannouncing to everyone else ensures that the transaction ripples through well\nconnected peers very fast and any degenerate part of the network is covered by\nannouncements. The ideal ratio of the split between broadcast and announce is\nthe topic of a different discussion.\n\nThe interesting tidbit for this PR is that the split between broadcast and\nannounce is currently done at random in Geth. We calculate that a new\ntransaction needs to be sent in full to N peers out of M, and just pick them at\nrandom. This randomness is very much desired as it ensures that the network load\ncaused by transactions is evenly distributed across all connections. As long as\ntransactions are arriving at a steady rate from different accounts, this\nmechanism works well. It doesn't matter who sends what, we randomly pass it\nacross the network and everyone will receive it one way or another.\n\nA problem arises however when there is a burst of transactions from the same\naccount (whether insta-sending K transactions or individually in very quick\nsuccession). The problem is that evaluating whom to send in full and whom to\nannounce by hash is evaluated randomly, independently across transactions.\n\nWith K transactions arriving simultaneously from the same account, those would\nget randomly broadcast across our peer set. With a probability of 1, all peers\nwill receive a sequence of nonce-gapped transactions, the gaps being announced\nonly. This is a double issue: nodes will only forward executable transactions,\nso whenever a peer encounters a nonce gap, propagation will be choked from that\npoint onward. Even though the gaps are announced, those will be received delayed\n(whether filled by someone else or needing explicit retrieval), time by which\nthe gapped transactions might already be dropped. The issue is even worse for K\ntransactions arriving individually in quick succession (say 50ms apart). There\nthe exact same problem arises, but we can't even try to group transactions by\naccount because we don't know what we've broadcast before and what future\ntransactions will arrive. Tracking broadcast targets across time is a non\ntrivial complexity. Geth's current solution to this problem is the transaction\npool. In the \"legacy\" pool, we track two sets of transactions: the pending set,\ncontaining all the executable transactions (no nonce gaps) and the queued set,\ncontaining a mixed bag of everything that's missing a nonce. As time passes and\ngaps are filled in, we move queued transactions to pending transactions. Whilst\nin theory workable, in practice this constant shuffling makes the pool extremely\nbrittle and easy to attack. The only way to simplify the pool and make it both\nmore robust and possibly have a larger capacity is to somehow get rid of this 2\nset complexity. For that to happen, we need to fix transaction propagation\nsomehow to get rid of nonce gaps altogether. Whilst it might be \"unfeasible\" to\nmake propagation 100% accurate and thus completely remove the pool's complexity;\nif we could make propagation almost-perfect, we could probably also very\nagressively simplify the txpool to only track a minimal subset of gaps for\n\"flukes\".\n\nCan we fix transaction propagation though? At least making it\n\"approximately-correct\". This PR is an attempt at saying Yes to that question.\nWhat we would like to achieve is to keep the current performance of transaction\npropagation (wrt bandwidth and latency), but avoid the nonce-gap-generation\nissue. The only way to do that is to ensure that if a tx is broadcast in full to\na peer, all subsequent txs from the same account are broadcast in full. If on\nthe other hand the tx is announced, all subsequent transactions are announced.\nThe naive solution of tracking what we sent to who is a can of worms nobody\nwants to open (especially when we would like this mechanism to work across a\nlonger time frame).\n\nThe solution this PR proposes, is to \"define\" a \"semi-stable\" transaction\nbroadcast/announce topology, where every node \"knows\" to whom they should\nbroadcast and to whom they should announce, without having a complete view of\nthe network or the transaction pool. It's ok if this \"topology\" is not\ncompletely stable, but it should be stable \"enough\" to capture\nsemi-instantaneous bursts and keep then on the same propagation path wrt\nbroadcasts/announce.\n\nInstead of picking sqrt peers at random to broadcast to; or instead of tracking\nto whom we've broadcasted before; the PR proposes to hash our own ID with a\npeer's ID and with the tx sender and use that checksum to select sqrt(peers) to\nbroadcast to. The elegance of this algorithm is that as long as I have a\nrelatively stable number of peers, the same peers will be selected over and over\nand over again for broadcasting, independent of what other peers are connected;\nand with exactly 0 state tracking. If enough peers join/leave to change the\nsqrt(peer) value, the topology will change, but apart from a startup wonkyness,\nthe connections and pathways will be stable most of the time.\n\nThe immediate upside is that nonce gaps should almost completely disappear (the\nmore other clients also chose to implement this (or any other stable topology,\ndoesn't have to be the same), the better the stability). With very minimised\nnonce gaps, we would be able to drastically simplify the txpool gapped tx\nhandling since that would be the exception, not the general rule. Also,\nimportant to highlight, this change is essentially free from all perspectives:\ncomputationally 0, complexity wise 0, effort wise to add to Geth or any other\nclient 0.","shortMessageHtmlLink":"eth: make transaction propagation paths in the network deterministic …"}},{"before":"1c73b9a85dbba88c50d861ed8ba95f60891ca1b1","after":"0f27ff6c34ab690a8a68e755ae08833b722c3c20","ref":"refs/heads/path-base-implementing","pushedAt":"2024-09-16T08:56:14.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"Francesco4203","name":null,"path":"/Francesco4203","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/100074926?s=80&v=4"},"commit":{"message":"all: move genesis init to blockchain (#570)\n\n* all: move genesis initialization to blockchain\n\n* all: fix test","shortMessageHtmlLink":"all: move genesis init to blockchain (#570)"}},{"before":"5dc0bd63d94a35d7ca36fd348243bb7904f2428a","after":"1c73b9a85dbba88c50d861ed8ba95f60891ca1b1","ref":"refs/heads/path-base-implementing","pushedAt":"2024-09-16T04:41:29.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"Francesco4203","name":null,"path":"/Francesco4203","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/100074926?s=80&v=4"},"commit":{"message":"all: move genesis init to blockchain (#570)\n\n* all: move genesis initialization to blockchain\r\n\r\n* all: fix test","shortMessageHtmlLink":"all: move genesis init to blockchain (#570)"}},{"before":"9b8ea2eecf41e9371729d085fbfe97929492921b","after":null,"ref":"refs/heads/change-ancient-chain-segments-from-root-ancient-to-sub-folders","pushedAt":"2024-09-13T08:49:44.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"}},{"before":"d7a987e84bea6c21400ee88823da666abd18858f","after":"5dc0bd63d94a35d7ca36fd348243bb7904f2428a","ref":"refs/heads/path-base-implementing","pushedAt":"2024-09-13T08:49:40.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"Change ancient chain segments from root ancient to sub folders (#572)\n\n* cmd, core, ethdb, node: rework ancient store folder reference by https://github.com/ethereum/go-ethereum/commit/e44d6551c3c872584722c366c863381f7e91df91","shortMessageHtmlLink":"Change ancient chain segments from root ancient to sub folders (#572)"}},{"before":"8f8fb6511193d189dc4de5516890f1c1d3fc5fc1","after":"9b8ea2eecf41e9371729d085fbfe97929492921b","ref":"refs/heads/change-ancient-chain-segments-from-root-ancient-to-sub-folders","pushedAt":"2024-09-13T08:34:20.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"huyngopt1994","name":"Harry Ngo","path":"/huyngopt1994","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17699212?s=80&v=4"},"commit":{"message":"fix: add check freezer path firstly","shortMessageHtmlLink":"fix: add check freezer path firstly"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0yMFQwMjo1ODoyMy4wMDAwMDBazwAAAAS7gPZu","startCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0yMFQwMjo1ODoyMy4wMDAwMDBazwAAAAS7gPZu","endCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0xM1QwODozNDoyMC4wMDAwMDBazwAAAAS1QE9b"}},"title":"Activity · axieinfinity/ronin"}