{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":157923543,"defaultBranch":"master","name":"eth2.0-specs","ownerLogin":"status-im","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2018-11-16T21:31:54.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/11767950?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1724680512.0","currentOid":""},"activityList":{"items":[{"before":"5761fb4d974b794d6d6dc0a0f82c3dff95ad618d","after":"0833551328dc94e6f55f514c806291bb99743e6a","ref":"refs/heads/single-attestation","pushedAt":"2024-08-28T05:35:16.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"spelling","shortMessageHtmlLink":"spelling"}},{"before":"0b95012c2ece8f12436727b4a2c0beb0c024cb4f","after":"5761fb4d974b794d6d6dc0a0f82c3dff95ad618d","ref":"refs/heads/single-attestation","pushedAt":"2024-08-28T05:32:02.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"update list of checks","shortMessageHtmlLink":"update list of checks"}},{"before":null,"after":"0b95012c2ece8f12436727b4a2c0beb0c024cb4f","ref":"refs/heads/single-attestation","pushedAt":"2024-08-26T13:55:12.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"Separate type for unaggregated network attestations\n\nAs a complement to\nhttps://github.com/ethereum/consensus-specs/pull/3787, this PR\nintroduces a `SingleAttestation` type used for network propagation only.\n\nIn Electra, the on-chain attestation format introduced in\n[EIP-7549](https://github.com/ethereum/consensus-specs/pull/3559)\npresents several difficulties - not only are the new fields to be\ninterpreted differently during network processing and onchain which adds\ncomplexity in clients, they also introduce inefficiency both in hash\ncomputation and bandwidth.\n\nThe new type puts the validator and committee indices directly in the\nattestation type, this simplifying processing and increasing security.\n\n* placing the validator index directly in the attestation allows\nverifying the signature without computing a shuffling - this closes a\nloophole where clients either must drop attestations or risk being\noverwhelmed by shuffling computations during attestation verification\n* the simpler \"structure\" of the attestation saves several hash calls\nduring processing (a single-item List has significant hashing overhead\ncompared to a field)\n* we save a few bytes here and there - we can also put stricter bounds\non message size on the attestation topic because `SingleAttestation` is\nnow fixed-size\n* the ambiguity of interpreting the `attestation_bits` list indices\nwhich became contextual under EIP-7549 is removed\n\nBecause this change only affects the network encoding (and not block\ncontents), the implementation impact on clients should be minimal.","shortMessageHtmlLink":"Separate type for unaggregated network attestations"}},{"before":"e4919d71d80cfc345dcd36cd81116190a51c8b32","after":"08e020e98d5fbeef8d49e1f074e0564df3ea85b7","ref":"refs/heads/remove-ttfb","pushedAt":"2024-08-23T11:38:29.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"remove timeout constants","shortMessageHtmlLink":"remove timeout constants"}},{"before":"f349bfcddc9dfc3d8719def876ad727dd8f8bc80","after":"e4919d71d80cfc345dcd36cd81116190a51c8b32","ref":"refs/heads/remove-ttfb","pushedAt":"2024-05-22T05:57:44.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"Update specs/phase0/p2p-interface.md\n\nCo-authored-by: Pop Chunhapanya ","shortMessageHtmlLink":"Update specs/phase0/p2p-interface.md"}},{"before":"f97538719ba4bcd08fbbc8601cc274e74a492066","after":"f349bfcddc9dfc3d8719def876ad727dd8f8bc80","ref":"refs/heads/remove-ttfb","pushedAt":"2024-05-21T11:21:29.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"lint","shortMessageHtmlLink":"lint"}},{"before":null,"after":"f97538719ba4bcd08fbbc8601cc274e74a492066","ref":"refs/heads/remove-ttfb","pushedAt":"2024-05-14T15:16:27.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"p2p: Deprecate TTFB, RESP_TIMEOUT, introduce rate limiting recommendations\n\nAs part of the discussions surrounding EIP-7594 (peerdas), it was\nhighlighted that during sampling and/or data requests, the sampler does\nnot have timing information for when a samplee will have data available.\nIt is desireable to not introduce a deadline, since this artificially\nintroduces latency for the typical scenario where data becomes available\nearlier than an agreed-upon deadline.\n\nSimilarly, when a client issues a request for blocks, it does often not\nknow what rate limiting policy of the serving end and must either\npessimistically rate limit itself or run the risk of getting\ndisconnected for spamming the server - outcomes which lead to\nunnecessarily slow syncing as well as testnet mess with peer scoring and\ndisconnection issues.\n\nThis PR solves both problems by:\n\n* removing the time-to-first-byte and response timeouts allowing\nrequesters to optimistically queue requests - the timeouts have\nhistorically not been implemented fully in clients to this date\n* introducing a hard limit in the number of concurrent requests that a\nclient may issue, per protocol\n* introducing a recommendation for rate limiting that allows optimal\nbandwidth usage without protocol changes or additional messaging\nroundtrips\n\nOn the server side, an \"open\" request does not consume significant\nresources while it's resting, meaning that allowing the server to manage\nresource allocation by slowing down data serving is safe, as long as\nconcurrency is adequately limited.\n\nOn the client side, clients must be prepared to handle slow servers\nalready and they can simply apply their existing strategy both to\nuncertainty and rate-limiting scenarios (how long before timeout, what\nto do in \"slow peer\" scenarios).\n\nToken / leaky buckets are a classic option for rate limiting with\ndesireable properties both for the case when we're sending requests to\nmany clients concurrently (getting good burst performance) and when the\nrequestees are busy (by keeping long-term resource usage in check and\nfairly serving clients)","shortMessageHtmlLink":"p2p: Deprecate TTFB, RESP_TIMEOUT, introduce rate limiting recommenda…"}},{"before":"1242368b58b96b01399feba0b80a2e9e23750469","after":null,"ref":"refs/heads/seen-ttl","pushedAt":"2024-03-29T02:29:34.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"hwwhww","name":"Hsiao-Wei Wang","path":"/hwwhww","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9263930?s=80&v=4"}},{"before":null,"after":"1242368b58b96b01399feba0b80a2e9e23750469","ref":"refs/heads/seen-ttl","pushedAt":"2024-03-19T07:54:39.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"Align `seen_ttl` with attestation lifetime\n\nhttps://github.com/ethereum/consensus-specs/pull/3360 effectively\nextends the valid lifetime of an attestation/aggregate to 2 epochs -\nthis means that an aggregate that was published at the beginning of a\nslot now is valid per the gossip rules up to 2 epochs later.\n\nThen net effect of the above change is that peers are allowed to\nrepublish old aggregates and attestations and libp2p will not stop the\nspread with the settings we recommend - instead the messages will have\nto be stopped with the \"attestation cover rule\" or similar, even though\nthey have been observed already.\n\nSignificant amounts of this kind of spam have been observed on the\naggregate channel in particular leading to a 5x increase in aggregate\ntraffic as some clients republish these old messages in spite of the\n\"attestation cover rule\" which should have stopped them - this simple\nchange will provide an additional layer of protection against such bugs.","shortMessageHtmlLink":"Align seen_ttl with attestation lifetime"}},{"before":"66082e3901b3564318629a803b96f6eb2f1b75b8","after":"04f5ec595d78c0e3e43794fb7644c18f2584770d","ref":"refs/heads/canonical-json-byte","pushedAt":"2023-11-09T06:51:51.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"remove obsolete comment","shortMessageHtmlLink":"remove obsolete comment"}},{"before":"f8c173c1b645deed90504ad90e810ded46c6fef4","after":"66082e3901b3564318629a803b96f6eb2f1b75b8","ref":"refs/heads/canonical-json-byte","pushedAt":"2023-10-17T09:41:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"revert ParticipationFlags back to `uint8`\n\nThis can be done separately in the future, if wanted","shortMessageHtmlLink":"revert ParticipationFlags back to uint8"}},{"before":"f2ad012cef187c11035174b733ecf0b23d3aa581","after":"f8c173c1b645deed90504ad90e810ded46c6fef4","ref":"refs/heads/canonical-json-byte","pushedAt":"2023-10-17T09:39:06.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"revert ParticipationFlags back to `byte`\n\nThis can be done separately in the future, if wanted","shortMessageHtmlLink":"revert ParticipationFlags back to byte"}},{"before":"fe95d7cb6d7f7e7b7667cd860808c43d7cb0ddb6","after":"f2ad012cef187c11035174b733ecf0b23d3aa581","ref":"refs/heads/canonical-json-byte","pushedAt":"2023-09-19T12:23:28.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"spelling bee and lint torture","shortMessageHtmlLink":"spelling bee and lint torture"}},{"before":null,"after":"fe95d7cb6d7f7e7b7667cd860808c43d7cb0ddb6","ref":"refs/heads/canonical-json-byte","pushedAt":"2023-09-19T12:11:53.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"ssz: `byte` type and canonical JSON mapping\n\nThis PR introduces a new `byte` type equivalent in all aspects to\n`uint8` except that it has additional intent and display semantics\nattached.\n\nOn top of this, the PR adds a canonical JSON mapping to the SSZ\nspecification, documenting current usage of JSON in tests, API:s and\nsimplifying future interop work between clients and adjacent\nspecifications such as the Beacon API. The encoding is appropriate to\nuse with YAML as well.\n\nAs an important property, this mapping contains a 1:1 mapping of SSZ\ntype to JSON encoding - this allows round-tripping any object between\nJSON and SSZ based on the SSZ schema and usage of the core SSZ types\nalone.\n\nThe encoding presented in this PR is used in tests and API:s with one\nexception: the `ParticipationFlags` type from the Altair spec - it is\nrecommended we switch encoding in tests and eventually the beacon API to\naddress this irregularity, so as to avoid a proliferation \"special\"\nprimitive types in the SSZ spec that only appear in particular schemas\n(and thus making validating general-purpose `SSZ/JSON` parsers more\ncomplex) as well as differences in encoding between fields of the same\nSSZ type.\n\nThe PR also clarifies that the introduction of new aliases does not lead\nto changes in their canonical JSON specification - this allows building\ngeneral SSZ/JSON libraries that do not further depend on open-ended\nknowledge about aliases.\n\nThis PR should be seen as an alternative to\nhttps://github.com/ethereum/consensus-specs/pull/2983.","shortMessageHtmlLink":"ssz: byte type and canonical JSON mapping"}},{"before":"ff9aa13462ade83b7221d0a4dc25415da13a3940","after":"bde91ac3f323f6a7cafbf8d0ea9cff23692fbea1","ref":"refs/heads/timings","pushedAt":"2023-09-15T08:38:55.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"hwwhww","name":"Hsiao-Wei Wang","path":"/hwwhww","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9263930?s=80&v=4"},"commit":{"message":"Fix `test_proposer_boost_root_same_slot_untimely_block`","shortMessageHtmlLink":"Fix test_proposer_boost_root_same_slot_untimely_block"}},{"before":"af727480e07b9a7e3ebf883a8ea6fc3b4fadfe44","after":"ff9aa13462ade83b7221d0a4dc25415da13a3940","ref":"refs/heads/timings","pushedAt":"2023-09-15T08:09:22.000Z","pushType":"push","commitsCount":123,"pusher":{"login":"hwwhww","name":"Hsiao-Wei Wang","path":"/hwwhww","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9263930?s=80&v=4"},"commit":{"message":"Merge branch 'dev' into pr3433","shortMessageHtmlLink":"Merge branch 'dev' into pr3433"}},{"before":"a235cef7cf9911b543295ab248f51d64215f3c51","after":"af727480e07b9a7e3ebf883a8ea6fc3b4fadfe44","ref":"refs/heads/timings","pushedAt":"2023-08-07T08:47:37.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"Introduce constants for due times, cutoffs\n\nAlso note potential for out-of-order messages","shortMessageHtmlLink":"Introduce constants for due times, cutoffs"}},{"before":"5fafcd82740391be851df9c4455da384d1226916","after":"a235cef7cf9911b543295ab248f51d64215f3c51","ref":"refs/heads/timings","pushedAt":"2023-06-16T06:48:11.539Z","pushType":"push","commitsCount":1,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"update forkchoice","shortMessageHtmlLink":"update forkchoice"}},{"before":"bf3e484207bf1b72e348cfc9dcf3a353ba326881","after":"5fafcd82740391be851df9c4455da384d1226916","ref":"refs/heads/timings","pushedAt":"2023-06-15T19:43:45.214Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"Rebalance duty times\n\nAs the chain keeps growing and duties are being added to the block\nconstruction and verification pipeline, it becomes increasingly\ndifficult for clients to complete block duties on time leading to poor\nattestation performance and reorg frequency increases.\n\nThis PR proposes to rebalance the relative timings of the 3 main\nactivites, namely block production, attestation and aggregation such\nthat they happen on 0/6/9 seconds into each slot instead of 0/4/8.\n\nThis reduces the time for attestations to reach aggregators and\naggregates to reach block producers but increases the time the consensus\nand execution clients have to produce and validate blocks.\n\nEach upgrade has so far increased complexity and processing requirements\naround block production and so will future upgraddes: due to increased\nsize, blocks with blobs will take longer to dissemenate and additional\nverification / cryptography is needed to validate them.","shortMessageHtmlLink":"Rebalance duty times"}},{"before":null,"after":"bf3e484207bf1b72e348cfc9dcf3a353ba326881","ref":"refs/heads/timings","pushedAt":"2023-06-15T19:42:13.025Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"arnetheduck","name":"Jacek Sieka","path":"/arnetheduck","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1382986?s=80&v=4"},"commit":{"message":"Rebalance duty times\n\nAs the chain keeps growing and duties are being added to the block\nconstruction and verification pipeline, it becomes increasingly\ndifficult for clients to complete block duties on time leading to poor\nattestation performance and reorg frequency increases.\n\nThis PR proposes to rebalance the relavite timings of the 3 main\nactivites, namely block production, attestation and aggregation such\nthat they happen on 0/6/9 seconds into each slot instead of 0/4/8.\n\nThis reduces the time for attestations to reach aggregators and\naggregates to reach block producers but increases the time the consensus\nand execution clients have to produce and validate blocks.\n\nEach upgrade has so far increased complexity and processing requirements\naround block production and so will future upgraddes: due to increased\nsize, blocks with blobs will take longer to dissemenate and additional\nverification / cryptography is needed to validate them.","shortMessageHtmlLink":"Rebalance duty times"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOC0yOFQwNTozNToxNi4wMDAwMDBazwAAAASmGDDJ","startCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOC0yOFQwNTozNToxNi4wMDAwMDBazwAAAASmGDDJ","endCursor":"Y3Vyc29yOnYyOpK7MjAyMy0wNi0xNVQxOTo0MjoxMy4wMjU2OTNazwAAAANCfwUq"}},"title":"Activity · status-im/eth2.0-specs"}