ePBS specs #1

terencechain · 2023-08-01T02:57:30Z

No description provided.

specs/_features/ePBS/p2p-interface.md

dapplion · 2023-08-01T08:12:31Z

specs/_features/ePBS/p2p-interface.md

+See gossip transition details found in the [Altair document](../altair/p2p-interface.md#transitioning-the-gossip) for
+details on how to handle transitioning gossip topics for this upgrade.
+
+### The Req/Resp domain


Block by root and by range will propagate full blocks (SignedBeaconBlock) or blinded blocks SignedBeaconBlockWithBid

This is a good question and I admit I haven't thought much on.
I think by range requires no changes. It's applied to finalized blocks anyway
By root is tricky, we might want to add a signed_blinded_block_by_root method

not sure why would signed by root be required for blinded except for those on the tip, but should be pickedup from gossip, anything missed from gossip can't be synced next slot by the time the payload is revealed (assuming that this ePBS scheme has payload reveal before last interval of the slot)

I think the notion of "full block" dissappears on ePBS. You request blocks and payloads separated, there's very little need to assemble a full block except for validation in which you get the two lists anyway as they perform separate state transitions on the beacon state.

dapplion · 2023-08-01T08:17:32Z

specs/_features/ePBS/p2p-interface.md

+- _[IGNORE]_ The signed builder bid value, `bid.value`, is less than builder's balance in state.
+- _[IGNORE]_ The signed builder header timestamp is correct with respect to next slot -- i.e. `header.timestamp == compute_timestamp_at_slot(state, current_slot + 1)`.
+- _[IGNORE]_ The signed builder header parent block has matches one of the chain tip in the fork choice store. Builder may submit multiple bids with respect to forks.
+- _[REJECT]_ The builder signature, `signed_bid.signature`, is valid with respect to the `bid.pubkey`.


each builder can publish an unbounded number of bids. How can we bound it? I would start by requiring increasing bids amounts to be at least % higher than previous

I am tempted to say we only allow one bid per builder per fork

+1 reject bids on same fork

If ePBS does not allow all features wanted by builders they will bypass ePBS and use side-channels. Re-bidding is key IMO, see current usage of mev-boost https://payload.de/data/

wow pretty interesting visualization, i guess re-bids with at least 10% increase would makes sense similar to tx acceptance

specs/_features/ePBS/p2p-interface.md

dapplion · 2023-08-01T08:22:01Z

specs/_features/ePBS/validator.md

+* Set `execution_attestation.slot = slot` where `slot` is the assigned slot.
+* Set `execution_attestation.block_hash = block_hash` where `block_hash` is the block hash seen from the block builder reveal at `SECONDS_PER_SLOT * 2 / INTERVALS_PER_SLOT`
+* Set `execution_attestation.validator_index = validator_index` where `validator_index` is the validator chosen to submit. The private key mapping to `state.validators[validator_index].pubkey` is used to sign the payload timeliness attestation.
+* Set `signed_execution_attestation = SignedExecution(message=execution_attestation, signature=execution_attestation_signature)`, where `execution_attestation_signature` is obtained from:


The PTC should cast a vote for either full or empty, does this data-structure allow empty votes?

Perhaps empty could be leveraged as zero hashes?

You still need to indicate that the payload for specifically header block_hash was not seen so that field must be set

dapplion · 2023-08-01T08:24:44Z

specs/_features/ePBS/validator.md

+
+Next, the validator creates `signed_execution_attestation`
+* Set `execution_attestation.slot = slot` where `slot` is the assigned slot.
+* Set `execution_attestation.block_hash = block_hash` where `block_hash` is the block hash seen from the block builder reveal at `SECONDS_PER_SLOT * 2 / INTERVALS_PER_SLOT`


Here block_hash refers to the SignedBeaconBlockWithBid hash tree root which is head at the builder reveal deadline?

g11tech · 2023-08-01T16:04:57Z

specs/_features/ePBS/p2p-interface.md

+
+- _[REJECT]_ The block's execution header timestamp is correct with respect to the slot -- i.e. `header.timestamp == compute_timestamp_at_slot(state, block.slot)`.
+- _[REJECT]_ The bid pubkey is a valid builder in state.
+- _[REJECT]_ The builder has sufficient balances to pay for the bid.


how would this be validated? won't this require access to execution state?

Bid payment is happening at consensus, not execution. @potuz should have a consensus spec soon

specs/_features/ePBS/validator.md

Co-authored-by: g11tech <develop@g11tech.io>

manav2401 · 2023-08-16T04:07:52Z

specs/_features/ePBS/p2p-design.md

+
+For the `value` check. A node must drop a bid if the builder does not have enough balance to pay for the bid plus maintain a self-min balance. I think `REJECT` makes more sense here. A node should not gossip about this because it's no use.
+
+For the `chain_extension` check. Suppose a chain has multiple tips. Builders maintain the same view. Competitive builders will be building simultaneously on all the tips. One paradigm shift is builder bid cancellation is no longer viable. This differs from the current mev-boost model. A node should `IGNORE` builder bids that are not top-of-the-chain tips. Worrying about DOS, a node can accept multiple bids of the same builder on the same tip, but the value has to be incremental. We need to think about this more.


How feasible it is to have a PriceBump field for bids similar to what we have in transaction pool? Only accept if the new bid for same tip is x% more than previous one.

Not really sure if it has to be enforced by the protocol or can be made configurable. Configurable might be favourable for some proposers.

potuz

First superficial pass, many comments.

potuz · 2023-09-06T12:42:45Z

specs/_features/ePBS/validator.md

+
+#### `get_inclusion_list`
+
+Given the `payload_id`, `get_payload` returns `GetInclusionListResponse` with the most recent version of


Are you sure you mean get_payload here? Also what do you mean by " the execution payload that has been built since the last FCU call"?

get_inclusion_list should simply return a current valid inclusion list.

potuz · 2023-09-06T12:43:00Z

specs/_features/ePBS/validator.md

+the execution payload that has been built since the corresponding call to `notify_forkchoice_updated` method.
+
+```python
+def get_inclusion_list(self: ExecutionEngine, payload_id: PayloadId) -> GetInclusionListResponse:


The type GetInclusionListResponse needs to be defined

potuz · 2023-09-06T12:57:02Z

specs/_features/ePBS/validator.md

+
+#### `get_inclusion_list`
+
+Given the `payload_id`, `get_payload` returns `GetInclusionListResponse` with the most recent version of


Why do we need a payload_id here? More generally, we need to be explicit that calls to FCU should not be sending the payload attributes anymore since proposers are not builders. And in the honest builder spec this should be specified. It's important to note that the typical validator should not be triggering block creation on their EL when proposing.

+1, I'll note this for the engine API spec. cc @naviechan

potuz · 2023-09-06T12:58:28Z

specs/_features/ePBS/validator.md

+
+## Validator assignment
+
+A validator can get PTC committee assignments for a given epoch using the following helper via `get_ptc_committee_assignment(state, epoch, validator_index)` where `epoch <= next_epoch`.


PTC assignments are by slot currently

potuz · 2023-09-06T12:59:40Z

specs/_features/ePBS/validator.md

+A validator can get PTC committee assignments for a given epoch using the following helper via `get_ptc_committee_assignment(state, epoch, validator_index)` where `epoch <= next_epoch`.
+
+A validator can use the following function to see if they are supposed to submit payload attestation message during a slot. 
+This function can only be run with a `state` of the slot in question. PTC committee selection is only stable within the context of the current and next epoch.


I think this should be a state, slot pair and allow this function to be called with any state.

potuz · 2023-09-06T13:23:33Z

specs/_features/ePBS/validator.md

+
+#### Aggregation selection
+
+A validator is selected to aggregate based upon the return value of `is_aggregator()`. [New in MaxEB]. Taken from [PR](https://github.com/michaelneuder/consensus-specs/pull/3)


Suggested change

A validator is selected to aggregate based upon the return value of `is_aggregator()`. [New in MaxEB]. Taken from [PR](https://github.com/michaelneuder/consensus-specs/pull/3)

A validator is selected to aggregate based upon the return value of `is_aggregator()`. [Modified in ePBS]. Taken from [PR](https://github.com/michaelneuder/consensus-specs/pull/3)

potuz · 2023-09-06T13:28:24Z

specs/_features/ePBS/validator.md

+
+### Payload timeliness attestation
+
+Some validators are selected to submit payload timeliness attestation. The `committee`, assigned `index`, and assigned `slot` for which the validator performs this role during an epoch are defined by `get_execution_committee(state, slot)`.


What is this function get_execution_committee?

potuz · 2023-09-06T13:29:29Z

specs/_features/ePBS/validator.md

+#### Constructing payload attestation
+
+##### Prepare payload attestation message
+If a validator is in the payload attestation committee (i.e. `is_assigned_to_payload_committee()` above returns True), 


Suggested change

If a validator is in the payload attestation committee (i.e. `is_assigned_to_payload_committee()` above returns True),

If a validator is in the payload attestation committee (i.e. `is_assigned_to_payload_committee()` below returns True),

potuz · 2023-09-06T13:30:28Z

specs/_features/ePBS/validator.md

+according to the logic in `get_payload_attestation_message` at `SECONDS_PER_SLOT * 3 / INTERVALS_PER_SLOT` interval.
+
+```python
+def is_assigned_to_payload_committee(state: BeaconState,


Do we really need a helper for validator_index in get_ptc(state, slot)?

potuz · 2023-09-06T13:31:19Z

specs/_features/ePBS/validator.md

+
+```python
+def get_payload_attestation_message_signature(state: BeaconState, attestation: PayloadAttestationMessage, privkey: int) -> BLSSignature:
+    domain = get_domain(state, DOMAIN_PAYLOAD_TIMELINESS_COMMITTEE, compute_epoch_at_slot(attestation.slot))


in https://github.com/potuz/consensus-specs/blob/epbs/specs/_features/epbs/beacon-chain.md#domain-types there's DOMAIN_PTC_ATTESTER

manav2401 · 2023-09-10T11:49:15Z

specs/_features/ePBS/validator.md

+
+To obtain an inclusion list, a block proposer building a block on top of a `state` must take the following actions:
+
+1. Retrieve inclusion list from execution layer by calling `get_execution_inclusion_list`.


I think proposer should also check if previous slot's payload was empty or not. If it was, the proposer shouldn't send a new inclusion list.

Okay I think this info has been added into the fork choice section by Potuz in a code snippet so not sure if we need it here.

potuz · 2023-09-11T11:35:28Z

specs/_features/ePBS/builder.md

+A builder is an entity that participates in the block building of the Ethereum proof-of-stake protocol. This is an optional role for users in which they can post ETH as collateral and build blocks to see financial returns in exchange for building the protocol.
+In this design, builder is an extension of validator using a different withdrawal prefix `0x0b`. The protocol onboards builder by upgrading validators into builders if minimal staked balance is reached.
+
+## Becoming a builder


A builder must keep a minimum balance of BUILDER_MIN_BALANCE in order to continue performing building duties.

specs/_features/ePBS/builder.md

potuz · 2023-09-11T11:39:11Z

specs/_features/ePBS/builder.md

+
+
+```python
+def prepare_execution_payload(state: BeaconState,


The payload attributes should contain the inclusion list summary at the very least, these are the txs that the payload will need to satisfy. The EL should have already cached the transactions when the builder notified of the IL before.

potuz · 2023-09-11T11:41:16Z

specs/_features/ePBS/builder.md

+
+#### Broadcast execution payload header envelope
+
+Finally, the validator broadcasts `signed_execution_payload_header_envelope` to the global `execution_payload_header_envelope` pubsub topic.


Why is this a global topic? only the proposer is interested in receiving this information, can this be made a smaller subset of the P2P network?

Good point. We can make this like the sync_committee_message subnet and only subscribe if you are proposing with an epoch look ahead

potuz · 2023-09-11T11:45:52Z

specs/_features/ePBS/builder.md

+
+#### Determine if it is safe to reveal
+
+The builder will call `get_head_block`. If the head block contains the payload header, then it is safe to reveal.


Not sure what the right wording is here. In principle the builder should reveal if he has seen any beacon block which is valid and included his payload. Head or not. The problem is that if the call to get_head_block returns another block, it will not have his header. If later the attestations switch back to the intended head, the builder will lose his bid.

potuz · 2023-09-11T11:46:12Z

specs/_features/ePBS/builder.md

+1. Build `ExecutionPayloadEnvelope`
+- Set `payload`  to the saved `execution_payload` from constructing the header.
+- Set `builder_index` to the index of the builder.
+- Set `beacon_block_root` to the head block root.


This is not necessarily the head block root, but rather the block root of the block that included his bid

specs/_features/ePBS/builder.md

potuz · 2023-09-11T11:49:27Z

specs/_features/ePBS/builder.md

+
+- Builder to proposer payment is unconditional after processing the signed execution payload header and the block remains head and canonical throughout. The builder will not lose the bid if the block is reorged.
+
+### Should the builder worry about same slot unbundling?


Do we really need a section about this?

Looking at the current specs, most have design rational sections rather than a separate design doc. I felt like if we were going to production this and get accepted by the upstream authors, a design rational section under respected domain may be the way to go. I don't feel strongly about this though

potuz · 2023-09-11T11:50:36Z

specs/_features/ePBS/builder.md

+
+### Should the builder worry about same slot unbundling?
+
+- There are cases to consider for same slot unbundling. the common case is proposer equivocate and broadcast the equivocated block to the network after builder has revealed the payload. In this case, the next slot proposer will also have to collude and build on the equivocated block.


Not only the next slot proposer but also a vast majority of the committee since attesters would have voted for the previous head.

potuz · 2023-09-11T11:51:15Z

specs/_features/ePBS/builder.md

+
+- There are cases to consider for same slot unbundling. the common case is proposer equivocate and broadcast the equivocated block to the network after builder has revealed the payload. In this case, the next slot proposer will also have to collude and build on the equivocated block.
+
+### What if builder sees proposer equivocate?


Do we need this section specified?

potuz · 2023-09-11T12:07:35Z

specs/_features/ePBS/p2p-interface.md

+*[New in ePBS]*
+
+```python
+class SignedNetworkBlock(Container):


What is this?

For syncing. It's a network wrapper. I'll add a design rationale for this today

potuz · 2023-09-11T12:09:35Z

specs/_features/ePBS/p2p-interface.md

+The following validations MUST pass before forwarding the `signed_execution_payload_envelope` on the network, assuming the alias `payload_envelope = signed_execution_payload_envelope.message`, `payload = payload_envelope.message.payload`:
+
+- _[IGNORE]_ The envelope's block root `payload_envelope.block_root` has been seen (via both gossip and non-gossip sources) (a client MAY queue payload for processing once the block is retrieved).
+- _[IGNORE]_ The hash tree root of the `payload` in `payload_envelope` matches the hash tree root of a payload header received previously on the `beacon_block` topic.


this should be a reject

potuz · 2023-09-11T12:10:04Z

specs/_features/ePBS/p2p-interface.md

+
+- _[IGNORE]_ The envelope's block root `payload_envelope.block_root` has been seen (via both gossip and non-gossip sources) (a client MAY queue payload for processing once the block is retrieved).
+- _[IGNORE]_ The hash tree root of the `payload` in `payload_envelope` matches the hash tree root of a payload header received previously on the `beacon_block` topic.
+- _[IGNORE]_ The builder index of the `payload_envelope` matches the payload header received previously on the `beacon_block` topic.


this should be a reject

potuz · 2023-09-11T12:13:03Z

specs/_features/ePBS/p2p-interface.md

+The following validations MUST pass before forwarding the `payload_attestation_message` on the network, assuming the alias `data = payload_attestation_message.data`:
+
+- _[IGNORE]_ `data.slot` is within the last `ATTESTATION_PROPAGATION_SLOT_RANGE` slots (with a MAXIMUM_GOSSIP_CLOCK_DISPARITY allowance) -- i.e. `data.slot` + `ATTESTATION_PROPAGATION_SLOT_RANGE` >= `current_slot` >= `data.slot` (a client MAY queue future aggregates for processing at the appropriate slot).
+- _[IGNORE]_ The attestation's `data.block_root` has been seen (via both gossip and non-gossip sources) (a client MAY queue attestation for processing once the block is retrieved. Note a client might want to request payload after).


Suggested change

- _[IGNORE]_ The attestation's `data.block_root` has been seen (via both gossip and non-gossip sources) (a client MAY queue attestation for processing once the block is retrieved. Note a client might want to request payload after).

- _[IGNORE]_ The attestation's `data.beacon_block_root` has been seen (via both gossip and non-gossip sources) (a client MAY queue attestation for processing once the block is retrieved. Note a client might want to request payload after).

potuz · 2023-09-11T12:14:30Z

specs/_features/ePBS/p2p-interface.md

+
+- _[IGNORE]_ `data.slot` is within the last `ATTESTATION_PROPAGATION_SLOT_RANGE` slots (with a MAXIMUM_GOSSIP_CLOCK_DISPARITY allowance) -- i.e. `data.slot` + `ATTESTATION_PROPAGATION_SLOT_RANGE` >= `current_slot` >= `data.slot` (a client MAY queue future aggregates for processing at the appropriate slot).
+- _[IGNORE]_ The attestation's `data.block_root` has been seen (via both gossip and non-gossip sources) (a client MAY queue attestation for processing once the block is retrieved. Note a client might want to request payload after).
+- _[REJECT]_ The validator index is within the payload committee in `get_ptc(state, slot)`.


Suggested change

- _[REJECT]_ The validator index is within the payload committee in `get_ptc(state, slot)`.

- _[REJECT]_ The validator index is within the payload committee in `get_ptc(state, data.slot)`.

potuz · 2023-09-11T12:16:35Z

specs/_features/ePBS/p2p-interface.md

+See gossip transition details found in the [Altair document](../altair/p2p-interface.md#transitioning-the-gossip) for
+details on how to handle transitioning gossip topics for this upgrade.
+
+### The Req/Resp domain


I think the notion of "full block" dissappears on ePBS. You request blocks and payloads separated, there's very little need to assemble a full block except for validation in which you get the two lists anyway as they perform separate state transitions on the beacon state.

potuz · 2023-09-11T12:17:05Z

specs/_features/ePBS/p2p-interface.md

+The following validations MUST pass before forwarding the `inclusion_list` on the network, assuming the alias `signed_summary = inclusion_list.summary`, `summary = signed_summary.message`:
+
+- _[REJECT]_ The inclusion list transactions `inclusion_list.transactions` length is within upperbound `MAX_TRANSACTIONS_PER_INCLUSION_LIST`.
+- _[REJECT]_ The inclusion list summery has the same length of transactions `len(summary.summary) == len(inclusion_list.transactions)`.


Suggested change

- _[REJECT]_ The inclusion list summery has the same length of transactions `len(summary.summary) == len(inclusion_list.transactions)`.

- _[REJECT]_ The inclusion list summary has the same length of transactions `len(summary.summary) == len(inclusion_list.transactions)`.

Co-authored-by: Potuz <potuz@potuz.net>

terencechain added 2 commits July 31, 2023 19:56

add epbs p2p spec

0ef2aa0

add epbs validator spec

6207e5f

dapplion reviewed Aug 1, 2023

View reviewed changes

g11tech reviewed Aug 1, 2023

View reviewed changes

terencechain force-pushed the epbs branch from 13486d0 to 2a63651 Compare August 1, 2023 22:32

add draft builder spec

435d4f4

terencechain force-pushed the epbs branch from 2a63651 to 435d4f4 Compare August 1, 2023 22:33

g11tech reviewed Aug 2, 2023

View reviewed changes

specs/_features/ePBS/validator.md Outdated Show resolved Hide resolved

terencechain and others added 3 commits August 2, 2023 10:31

Update specs/_features/ePBS/validator.md

f009012

Co-authored-by: g11tech <develop@g11tech.io>

Update p2p spec with Potuz changes

4bfb350

Add p2p design notes

e6ac60e

manav2401 reviewed Aug 16, 2023

View reviewed changes

terencechain added 5 commits August 28, 2023 11:49

Update p2p spec with inclusion list

eefb9ab

Add network block by range and root

3735218

Update p2p structs

860d88e

update validator spec

1c27029

update validator spec

b791979

potuz reviewed Sep 6, 2023

View reviewed changes

Potuz feedback

b519044

terencechain force-pushed the epbs branch from a2b6382 to b519044 Compare September 6, 2023 16:14

terencechain added 4 commits September 6, 2023 11:34

Specify old block root for payload attestation and fix inclusion list

f565ae6

first pass at builder

29f12d5

builder rought draft done

04f5e5f

validator spec clean up

991ed24

manav2401 reviewed Sep 10, 2023

View reviewed changes

potuz reviewed Sep 11, 2023

View reviewed changes

terencechain and others added 3 commits September 11, 2023 07:36

Potuz's edits

f4a3a05

Co-authored-by: Potuz <potuz@potuz.net>

Potuz feedback

da404b3

update inclusion list p2p section

861de11

terencechain added 4 commits September 12, 2023 15:02

use inclusion list summary for payload attribute call

7c79586

add more color around inclusion list behavior on skip slot

582ba08

PTC committee can ignore attestaitons

bcd6f8d

use get_blockhash

6913f0d


		For the `value` check. A node must drop a bid if the builder does not have enough balance to pay for the bid plus maintain a self-min balance. I think `REJECT` makes more sense here. A node should not gossip about this because it's no use.

		For the `chain_extension` check. Suppose a chain has multiple tips. Builders maintain the same view. Competitive builders will be building simultaneously on all the tips. One paradigm shift is builder bid cancellation is no longer viable. This differs from the current mev-boost model. A node should `IGNORE` builder bids that are not top-of-the-chain tips. Worrying about DOS, a node can accept multiple bids of the same builder on the same tip, but the value has to be incremental. We need to think about this more.


		#### `get_inclusion_list`

		Given the `payload_id`, `get_payload` returns `GetInclusionListResponse` with the most recent version of


		## Validator assignment

		A validator can get PTC committee assignments for a given epoch using the following helper via `get_ptc_committee_assignment(state, epoch, validator_index)` where `epoch <= next_epoch`.


		#### Aggregation selection

		A validator is selected to aggregate based upon the return value of `is_aggregator()`. [New in MaxEB]. Taken from [PR](https://github.com/michaelneuder/consensus-specs/pull/3)


		### Payload timeliness attestation

		Some validators are selected to submit payload timeliness attestation. The `committee`, assigned `index`, and assigned `slot` for which the validator performs this role during an epoch are defined by `get_execution_committee(state, slot)`.

	If a validator is in the payload attestation committee (i.e. `is_assigned_to_payload_committee()` above returns True),
	If a validator is in the payload attestation committee (i.e. `is_assigned_to_payload_committee()` below returns True),


		To obtain an inclusion list, a block proposer building a block on top of a `state` must take the following actions:

		1. Retrieve inclusion list from execution layer by calling `get_execution_inclusion_list`.


		#### Broadcast execution payload header envelope

		Finally, the validator broadcasts `signed_execution_payload_header_envelope` to the global `execution_payload_header_envelope` pubsub topic.


		#### Determine if it is safe to reveal

		The builder will call `get_head_block`. If the head block contains the payload header, then it is safe to reveal.


		- Builder to proposer payment is unconditional after processing the signed execution payload header and the block remains head and canonical throughout. The builder will not lose the bid if the block is reorged.

		### Should the builder worry about same slot unbundling?



		```python
		def prepare_execution_payload(state: BeaconState,


		### Should the builder worry about same slot unbundling?

		- There are cases to consider for same slot unbundling. the common case is proposer equivocate and broadcast the equivocated block to the network after builder has revealed the payload. In this case, the next slot proposer will also have to collude and build on the equivocated block.


		- There are cases to consider for same slot unbundling. the common case is proposer equivocate and broadcast the equivocated block to the network after builder has revealed the payload. In this case, the next slot proposer will also have to collude and build on the equivocated block.

		### What if builder sees proposer equivocate?

	- _[IGNORE]_ The attestation's `data.block_root` has been seen (via both gossip and non-gossip sources) (a client MAY queue attestation for processing once the block is retrieved. Note a client might want to request payload after).
	- _[IGNORE]_ The attestation's `data.beacon_block_root` has been seen (via both gossip and non-gossip sources) (a client MAY queue attestation for processing once the block is retrieved. Note a client might want to request payload after).

	- _[REJECT]_ The validator index is within the payload committee in `get_ptc(state, slot)`.
	- _[REJECT]_ The validator index is within the payload committee in `get_ptc(state, data.slot)`.

	- _[REJECT]_ The inclusion list summery has the same length of transactions `len(summary.summary) == len(inclusion_list.transactions)`.
	- _[REJECT]_ The inclusion list summary has the same length of transactions `len(summary.summary) == len(inclusion_list.transactions)`.

ePBS specs #1

Are you sure you want to change the base?

ePBS specs #1

Conversation

terencechain commented Aug 1, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

potuz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

terencechain commented Aug 1, 2023 •

edited

Loading