Separate type for unaggregated network attestations #14659

rkapka · 2024-11-22T16:55:19Z

What type of PR is this?

Feature

What does this PR do? Why is it needed?

Implements ethereum/consensus-specs#3900

New changes after initial reviews

I created new signed and unsigned AggregateAndProof types that hold SingleAttestation, which is needed to be able to save single attestations into pending atts, and simplified GetCommitteeIndex so that it doesn't return an error. Returning errors on getters is always very annoying to deal with, and we shouldn't get into the error scenario in the first place (most, if not all, potential errors are already handled in gossip checks).
I save the new SignedAggregateAttestationAndProofSingle type to pending atts and convert the underlying attestation into an AttestationElectra when processing this attestation. This is after validateUnaggregatedAttWithState.
validateUnaggregatedAttWithState returns the committee so that we can convert the attestation.
I removed the validateBitLength helper because I need the committee outside of this function too, and it's already available before the function call. So calling VerifyBitfieldLength directly is simpler.
I renamed validateCommitteeIndexAndCount to validateCommitteeIndex as that's how it was called before Electra changes. We don't need the Electra validateCommitteeIndex and validateCommitteeIndexElectra functions because their main purpose was to validate the Electra version, and it's no longer needed with single attestation (there is validateAttestingIndex instead)

Original description

The above consensus change introduces a new SingleAttestation type for unaggregated attestations. AttestationElectra will still be used for aggregated atts. Using the single version in all of our code would be a huge undertaking because many components, such as the attestation pool and attestation caches, require attestations to be of the old format. Modifying these components to work both with pre-Electra attestations and the single attestation is risky and too much work for Pectra.

The main reason why SingleAttestation was introduced is to prevent a DoS attack, which means it's main value is at the level of gossip. Once we pass gossip validation checks, there is no downside to using the AttestationElectra for unaggregated attestations too. This allows us to leave most attestation-related code untouched. To have the best of both worlds, we convert the single attestation to an Electra attestation as quickly as possible and use the latter from that point on.

When converting from SingleAttestation to ElectraAttestation we need to find the index within the committee of the attester_index from the single attestation, because attester_index is the validator index within the whole state. To give an example:

Validator 9999 is an attester and the committee index to which it is assigned is 5. Within committee number 5, the attester's position/index is 7. SingleAttestation's values will be attester_index = 9999 and committee_index = 5. When converting to an ElectraAttestation, we need to set bit number 7 in attestation_bits. We need to obtain the number 7 somehow as it is not present in the SingleAttestation.

The way it's done is by using the AttestationStateFetcher to get the attestation's target state, then get the appropriate committee from that state and lastly call ToAttestationElectra on the SingleAttestation, passing the committee to the function.

Other notes for review

Obtaining the target state, getting the committee and converting takes less than 1ms. I presume it's because both the state and committee are cached.
Tested on Kurtosis with Prysm-only nodes and and Prysm+Lodestar.
The same "convert quickly to Electra attestation" design is what other clients are doing too to minimize disruption.

Acknowledgements

I have read CONTRIBUTING.md.
I have made an appropriate entry to CHANGELOG.md.
I have added a description to this PR with sufficient context for reviewers to understand this PR.

# Conflicts: # proto/prysm/v1alpha1/electra.ssz.go

beacon-chain/sync/validate_aggregate_proof_test.go

terencechain · 2024-12-12T02:57:39Z

beacon-chain/sync/validate_beacon_attestation.go

+
+	preState, err := s.cfg.chain.AttestationTargetState(ctx, data.Target)
+	if err != nil {
+		tracing.AnnotateError(span, err)
+		return pubsub.ValidationIgnore, err
+	}
+	committeeIndex, err := att.GetCommitteeIndex()
+	if err != nil {
+		tracing.AnnotateError(span, err)
+		return pubsub.ValidationIgnore, err
+	}
+	committee, err := helpers.BeaconCommitteeFromState(ctx, preState, att.GetData().Slot, committeeIndex)
+	if err != nil {
+		tracing.AnnotateError(span, err)
+		return pubsub.ValidationIgnore, err
+	}
+
+	var singleAtt *eth.SingleAttestation
+	if att.Version() >= version.Electra {
+		singleAtt, ok = att.(*eth.SingleAttestation)
+		if !ok {
+			return pubsub.ValidationIgnore, fmt.Errorf("attestation has wrong type (expected %T, got %T)", &eth.SingleAttestation{}, att)
+		}
+		att = singleAtt.ToAttestationElectra(committee)
+	}
+


Is there a DOS vector for calling AttestationTargetState and BeaconCommitteeFromState this early?

terencechain · 2024-12-12T02:58:58Z

validator/client/beacon-api/propose_attestation_test.go

-			name: "nil signature",
-			attestation: &ethpb.AttestationElectra{
-				AggregationBits: testhelpers.FillByteSlice(4, 74),
-				Data: &ethpb.AttestationData{
-					Source: &ethpb.Checkpoint{},
-					Target: &ethpb.Checkpoint{},
-				},
-				CommitteeBits: testhelpers.FillByteSlice(8, 83),
-			},
-			expectedErrorMessage: "attestation signature can't be nil",


Why nil signature test removed?

I removed it because we had two functions in the codebase checking if an attestation is nil. One is helpers.ValidateNilAttestation and the other one is validateNilAttestation on the VC side. The only difference between them was signature validation which is missing in the helpers package. I decided it's better to just have a single implementation and I expect the one in helpers to be more accurate. I am not exactly sure what happens though when the BN receives an attestation without a signature if the function in helpers doesn't fail (most likely signature validation fails in some other place).

terencechain · 2024-12-12T03:08:14Z

beacon-chain/sync/validate_beacon_attestation.go

+		if !ok {
+			return pubsub.ValidationIgnore, fmt.Errorf("attestation has wrong type (expected %T, got %T)", &eth.SingleAttestation{}, att)
+		}
+		att = singleAtt.ToAttestationElectra(committee)


This is the biggest additional performance penalty as far as I can see. For a node that subscribe to several subnets. Is this a concern? We will call this 10-30k times per slot

nisdas · 2024-12-12T04:38:58Z

beacon-chain/sync/validate_beacon_attestation.go

@@ -71,6 +70,32 @@ func (s *Service) validateCommitteeIndexBeaconAttestation(ctx context.Context, p
 	if data.Slot == 0 {
 		return pubsub.ValidationIgnore, nil
 	}
+
+	preState, err := s.cfg.chain.AttestationTargetState(ctx, data.Target)


Why are we calling this here ? There must be strong justification for

fetching a state

fetching the committee from it

As these are additional bottlenecks on our highest traffic gossip path

Also why is this being called before the current gossip checks

beacon-chain/sync/validate_aggregate_proof.go

nisdas · 2024-12-17T06:41:29Z

beacon-chain/sync/validate_beacon_attestation.go

-	committee, result, err := s.validateBitLength(ctx, bs, a.GetData().Slot, committeeIndex, a.GetAggregationBits())
-	if result != pubsub.ValidationAccept {
-		return result, err
+	committee, err := helpers.BeaconCommitteeFromState(ctx, bs, a.GetData().Slot, committeeIndex)


Same here, why is validateBitLength removed

nisdas · 2024-12-17T06:44:29Z

beacon-chain/sync/validate_beacon_attestation.go

@@ -115,6 +104,48 @@ func (s *Service) validateCommitteeIndexBeaconAttestation(ctx context.Context, p
 		}
 	}

+	if !s.cfg.chain.InForkchoice(bytesutil.ToBytes32(data.BeaconBlockRoot)) {


Executing all these methods before we have validated data.BeaconBlockRoot is wrong. As we might have not processed the block yet (and it has to be inserted into our pending queue)

nisdas · 2024-12-17T06:45:22Z

beacon-chain/sync/validate_beacon_attestation.go

+		return pubsub.ValidationIgnore, blockchain.ErrNotDescendantOfFinalized
+	}
+
+	if err = s.cfg.chain.VerifyLmdFfgConsistency(ctx, att); err != nil {


Same here and for the rest of the methods that follow it. If it is difficult enough, you should just stream the attestations after

beacon-chain/sync/validate_beacon_attestation.go

potuz

First pass, will continue in 30 minutes

potuz · 2025-01-07T12:19:07Z

beacon-chain/core/helpers/attestation.go

+	if !attestation.IsSingle() && attestation.GetAggregationBits() == nil {
 		return errors.New("attestation's bitfield can't be nil")
 	}
 	return nil


Suggested change

if !attestation.IsSingle() && attestation.GetAggregationBits() == nil {

return errors.New("attestation's bitfield can't be nil")

}

return nil

if attestation.IsSingle() {

return nil

}

if attestation.GetAggregationBits() == nil {

return errors.New("attestation's bitfield can't be nil")

}

return nil

potuz · 2025-01-07T12:21:27Z

beacon-chain/core/helpers/attestation.go

@@ -32,7 +32,7 @@ func ValidateNilAttestation(attestation ethpb.Att) error {
 	if attestation.GetData().Target == nil {
 		return errors.New("attestation's target can't be nil")
 	}
-	if attestation.GetAggregationBits() == nil {
+	if !attestation.IsSingle() && attestation.GetAggregationBits() == nil {


I think attestation.IsNil should handle this check and this function ValidateNilAttestation should not even exist.

I will add this comment to my follow-up list

potuz · 2025-01-07T12:23:14Z

beacon-chain/core/helpers/attestation_test.go

@@ -308,6 +308,16 @@ func TestValidateNilAttestation(t *testing.T) {
 			},
 			errString: "",
 		},
+		{


A case with a ethpb.SingleAttestation and nil failures is missing.

Yes, but this is because there is no additional logic for single attestations. I can still add these tests if you feel strongly about it, but I don't see that much value in copy-pasting tests for different types when the logic is exactly the same

potuz · 2025-01-07T12:44:47Z

api/server/structs/other.go

@@ -36,6 +36,13 @@ type AttestationElectra struct {
 	CommitteeBits   string           `json:"committee_bits"`
 }

+type SingleAttestation struct {


Do we still need the structure AttestationElectra? shouldn't this be removed? I understand that we still need it in consensus, but how about in the API here?

I think AttestationElectra is still part of beacon block so it's needed for block related api end points right?

potuz · 2025-01-07T12:57:24Z

beacon-chain/rpc/eth/beacon/handlers_pool.go

+		if err != nil {
+			return nil, nil, errors.Wrap(err, "could not get target state for attestation")
+		}
+		committee, err := corehelpers.BeaconCommitteeFromState(ctx, targetState, att.Data.Slot, att.CommitteeId)


Not part of this PR but the bad design here is that we can only access the beacon committee while holding the state, when most of the time this committee is already cached. We should have a method to access the beacon committee from the checkpoint and only handle the failure withing that method, that is, the function would be BeaconCommitteeFromCheckpoint(cp, committeeId) and within that function we should check the committee cache, if it fails, then it should request a state and try to get it from the state.

potuz · 2025-01-07T13:03:13Z

beacon-chain/rpc/eth/beacon/handlers_pool.go

+		if err != nil {
+			return nil, nil, errors.Wrap(err, "could not get committee for attestation")
+		}
+
 		// Broadcast the unaggregated attestation on a feed to notify other services in the beacon node
 		// of a received unaggregated attestation.
 		// Note we can't send for aggregated att because we don't have selection proof.
 		if !att.IsAggregated() {


This check is useless, the structure SingleAttestation always returns false here.

potuz · 2025-01-07T13:05:53Z

beacon-chain/rpc/eth/beacon/handlers_pool.go

 		if err = s.Broadcaster.BroadcastAttestation(ctx, subnet, att); err != nil {
 			log.WithError(err).Errorf("could not broadcast attestation at index %d", i)
 			failedBroadcasts = append(failedBroadcasts, strconv.Itoa(i))
 			continue
 		}

 		if features.Get().EnableExperimentalAttestationPool {
-			if err = s.AttestationCache.Add(att); err != nil {
+			if err = s.AttestationCache.Add(att.ToAttestationElectra(committee)); err != nil {


The conversion to ToAttestationElectra happens unconditionally above, I would keep this object and reuse it here.

potuz · 2025-01-07T13:06:37Z

beacon-chain/rpc/eth/beacon/handlers_pool.go

 		} else {
-			if err = s.AttestationsPool.SaveUnaggregatedAttestation(att); err != nil {
-				log.WithError(err).Error("could not save unaggregated attestation")
+			if err = s.AttestationsPool.SaveUnaggregatedAttestation(att.ToAttestationElectra(committee)); err != nil {


potuz · 2025-01-07T13:30:07Z

beacon-chain/rpc/eth/validator/handlers.go

@@ -205,11 +205,7 @@ func matchingAtts(atts []ethpbalpha.Att, slot primitives.Slot, attDataRoot []byt
 		// compare the committee index separately.
 		if postElectra {
 			if att.Version() >= version.Electra {


The whole block reads better as follows

root, err := att.GetData().HashTreeRoot() if err != nil { return nil, errors.Wrap(err, "could not get attestation data root") } if !bytes.Equal(root[:], attDataRoot) { continue } if att.Version() < version.Electra || (postElectra && att.GetCommitteeIndex() == index) { result = append(result, att) }

Agreed, but we need to have (!postElectra && att.Version() < version.Electra) || ...

that should be covered for att.Version() < version.Electra since we should clean the pool at the fork, but anyway you can change the first side of the || to include the check

if (!postElectra && att.Version() < version.Electra) || (postElectra && att.GetCommitteeIndex() == index) {

terencechain · 2025-01-07T17:32:58Z

beacon-chain/rpc/eth/beacon/handlers_pool.go

-			return nil, nil, errors.Wrap(err, "failed to retrieve attestation committee index")
-		}
-		subnet := corehelpers.ComputeSubnetFromCommitteeAndSlot(uint64(len(vals)), committeeIndex, att.Data.Slot)
+		subnet := corehelpers.ComputeSubnetFromCommitteeAndSlot(uint64(len(vals)), att.GetCommitteeIndex(), att.Data.Slot)


Unrelated to this PR but calling s.HeadFetcher.HeadValidatorsIndices(ctx, wantedEpoch) in the event of a cache miss will allocate a new slice of active validator indices, it's expensive to just get the active validator count. ActiveValidatorCount is more suitable for this

I will add this comment to my follow-up list

terencechain · 2025-01-07T17:37:03Z

beacon-chain/rpc/prysm/v1alpha1/validator/attester.go

 	if err != nil {
 		return nil, err
 	}

 	if features.Get().EnableExperimentalAttestationPool {
-		if err = vs.AttestationCache.Add(att); err != nil {
+		if err = vs.AttestationCache.Add(att.ToAttestationElectra(committee)); err != nil {


may be able to reuse att.ToAttestationElectra(committee) here

terencechain · 2025-01-07T17:48:22Z

beacon-chain/rpc/prysm/v1alpha1/validator/attester.go

+func (vs *Server) proposeAtt(
+	ctx context.Context,
+	att ethpb.Att,
+	committee []primitives.ValidatorIndex, // required post-Electra


I don't understand as to why committee is needed here.
ProposeAttestationElectra calls this function and is already passing in SingleAttestation
BroadcastAttestation doesn't require committee

you need the committee to convert the attestation to an electra attestation to send the feed... perhaps that can be taken away

That's what I thought initially, but after looking closer, the feed takes ethpb.Att, which a single attestation already satisfies. It should theoretically work if I just pass in SingleAttestation to the feed, unless there's something on the receiver side that specifically requires electra attestation and not single attestation. In that case, I would argue that the receiver should fix that.

Example, this will build:

func (vs *Server) proposeAtt( ctx context.Context, att ethpb.Att, committeeIndex primitives.CommitteeIndex, ) (*ethpb.AttestResponse, error) { vs.OperationNotifier.OperationFeed().Send(&feed.Event{ Type: operation.UnaggregatedAttReceived, Data: &operation.UnAggregatedAttReceivedData{ Attestation: att, }, }) subnet := helpers.ComputeSubnetFromCommitteeAndSlot(uint64(len(vals)), committeeIndex, att.GetData().Slot) if err := vs.P2P.BroadcastAttestation(ctx, subnet, att); err != nil { return nil, status.Errorf(codes.Internal, "Could not broadcast attestation: %v", err) } }

Discussed offline, we'll take the internal type to track a bit field such that we wont have to be passing committee around

terencechain · 2025-01-07T17:54:15Z

proto/prysm/v1alpha1/attestation.proto

+message SignedAggregateAttestationAndProofSingle {
+    // The aggregated attestation and selection proof itself.
+    AggregateAttestationAndProofSingle message = 1;
+
+    // 96 byte BLS aggregate signature signed by the aggregator over the message.
+    bytes signature = 2 [(ethereum.eth.ext.ssz_size) = "96"];
+}
+
+message AggregateAttestationAndProofSingle {
+    // The aggregator index that submitted this aggregated attestation and proof.
+    uint64 aggregator_index = 1  [(ethereum.eth.ext.cast_type) = "github.com/prysmaticlabs/prysm/v5/consensus-types/primitives.ValidatorIndex"];
+
+    // The aggregated attestation that was submitted.
+    SingleAttestation aggregate = 3;
+
+    // 96 byte selection proof signed by the aggregator, which is the signature of the slot to aggregate.


My understanding is that this is required because of the savePendingAtt API. It seems annoying to define new proto types just to satisfy an API for the cache savePendingAtt. I wonder if there's something we can do to fix the cache for the API; probably a subsequent PR is okay

The pending atts queue would have to be redesigned so that you don't have to save AggregateAttestationAndProof objects. We currently construct dummy objects just to satisfy the interface. I will add this to my todo list.

# Conflicts: # CHANGELOG.md # proto/prysm/v1alpha1/validator.pb.go

potuz · 2025-01-09T12:55:06Z

beacon-chain/sync/pending_attestations_queue.go

+	if att.Version() >= version.Electra {
+		var ok bool
+		singleAtt, ok = att.(*ethpb.SingleAttestation)
+		if !ok {


I have a question on this path. According to the Electra spec AggregateAndProof here contains an Attestation object inside which is never a SingleAttestation according to this definition in the Electra spec

potuz

Have a concern in the pending attestation queue

potuz

Another quick pass, logic looks good to me except some nasty hacks to deal with the pending queue

beacon-chain/sync/validate_beacon_attestation.go

potuz · 2025-01-09T13:25:58Z

beacon-chain/sync/validate_beacon_attestation.go

 			}
-			s.savePendingAtt(&eth.SignedAggregateAttestationAndProofElectra{Message: &eth.AggregateAttestationAndProofElectra{Aggregate: a}})
+			s.savePendingAtt(&eth.SignedAggregateAttestationAndProofSingle{Message: &eth.AggregateAttestationAndProofSingle{Aggregate: a}})


Document this hack please

potuz · 2025-01-09T13:26:48Z

beacon-chain/sync/validate_beacon_attestation.go

@@ -115,17 +99,19 @@ func (s *Service) validateCommitteeIndexBeaconAttestation(ctx context.Context, p
 		}
 	}

+	var validationRes pubsub.ValidationResult
+
 	// Verify the block being voted and the processed state is in beaconDB and the block has passed validation if it's in the beaconDB.
 	blockRoot := bytesutil.ToBytes32(data.BeaconBlockRoot)
 	if !s.hasBlockAndState(ctx, blockRoot) {


Perhaps this whole block can be extracted from this function

potuz · 2025-01-09T13:34:50Z

beacon-chain/sync/validate_beacon_attestation.go

+		if !ok {
+			return pubsub.ValidationIgnore, fmt.Errorf("attestation has wrong type (expected %T, got %T)", &eth.SingleAttestation{}, a)
+		}
+		result, err := validateAttestingIndex(ctx, singleAtt.AttesterIndex, committee)


Suggested change

result, err := validateAttestingIndex(ctx, singleAtt.AttesterIndex, committee)

return validateAttestingIndex(ctx, singleAtt.AttesterIndex, committee)

And then remove the else branch

This reverts commit 153d187.

rkapka added 11 commits November 22, 2024 17:43

definitions and gossip

f9232df

Merge branch '__develop' into single-att

76de5f4

validator

e741580

broadcast

df5338a

broadcast the correct att depending on version

c8ecac2

Merge branch '__develop' into single-att

a32321f

small updates

4215a95

don't check bits after Electra

fd296d9

nitpick

67e92e0

Merge branch '__develop' into single-att

12795fb

# Conflicts: # proto/prysm/v1alpha1/electra.ssz.go

tests

9d70083

rkapka marked this pull request as ready for review December 10, 2024 22:00

rkapka requested a review from a team as a code owner December 10, 2024 22:00

rkapka requested review from prestonvanloon, saolyn and potuz December 10, 2024 22:00

rkapka changed the title ~~Single att~~ Separate type for unaggregated network attestations Dec 10, 2024

rkapka and others added 2 commits December 11, 2024 12:23

changelog <3

b04ccbe

Merge branch 'develop' into single-att

cb58bd1

terencechain reviewed Dec 12, 2024

View reviewed changes

nisdas reviewed Dec 12, 2024

View reviewed changes

review

d3387b3

nisdas reviewed Dec 17, 2024

View reviewed changes

more review

a9f3844

terencechain previously approved these changes Dec 22, 2024

View reviewed changes

potuz requested changes Dec 23, 2024

View reviewed changes

beacon-chain/sync/validate_beacon_attestation.go Show resolved Hide resolved

review yet again

abf7e6d

rkapka dismissed terencechain’s stale review via abf7e6d December 23, 2024 10:41

try a different design

023c99d

rkapka force-pushed the single-att branch from e8f0569 to 023c99d Compare December 23, 2024 17:12

rkapka added 3 commits January 7, 2025 14:27

Preston's review

82eeb8d

Merge branch '__develop' into single-att

c13b7a1

move changelog entry to unreleased section

4704dd3

potuz reviewed Jan 7, 2025

View reviewed changes

terencechain reviewed Jan 7, 2025

View reviewed changes

rkapka added 3 commits January 8, 2025 18:03

fix pending atts pool issues

324d6aa

reviews

4053c78

Merge branch '__develop' into single-att

3a2b677

# Conflicts: # CHANGELOG.md # proto/prysm/v1alpha1/validator.pb.go

potuz reviewed Jan 9, 2025

View reviewed changes

rkapka and others added 4 commits January 9, 2025 14:56

Potuz's comments

12c80f1

test fixes

d3228b6

Merge branch '__develop' into single-att

0c2da4d

Merge branch 'develop' into single-att

41e5368

potuz approved these changes Jan 10, 2025

View reviewed changes

rkapka added this pull request to the merge queue Jan 10, 2025

rkapka removed this pull request from the merge queue due to a manual request Jan 10, 2025

rkapka added Electra electra hardfork >1 Approves Required labels Jan 10, 2025

nisdas approved these changes Jan 11, 2025

View reviewed changes

rkapka added this pull request to the merge queue Jan 13, 2025

prestonvanloon approved these changes Jan 13, 2025

View reviewed changes

Merged via the queue into develop with commit 153d187 Jan 13, 2025
15 checks passed

rkapka deleted the single-att branch January 13, 2025 17:11

nalepae added a commit that referenced this pull request Jan 15, 2025

Revert "Separate type for unaggregated network attestations (#14659)"

d545409

This reverts commit 153d187.

	result, err := validateAttestingIndex(ctx, singleAtt.AttesterIndex, committee)
	return validateAttestingIndex(ctx, singleAtt.AttesterIndex, committee)

Separate type for unaggregated network attestations #14659

Separate type for unaggregated network attestations #14659

Conversation

rkapka commented Nov 22, 2024 • edited Loading

New changes after initial reviews

Original description

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rkapka Dec 18, 2024 • 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

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

terencechain Jan 7, 2025 • 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

rkapka Jan 8, 2025 • edited Loading

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

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

rkapka commented Nov 22, 2024 •

edited

Loading

rkapka Dec 18, 2024 •

edited

Loading

terencechain Jan 7, 2025 •

edited

Loading

rkapka Jan 8, 2025 •

edited

Loading