Update EIP-4762: reworked gas schedule from interop #8550

gballet · 2024-05-13T05:00:24Z

For reference: https://notes.ethereum.org/EHXrhQ8-QdeqnqLH3-KBuw?view

eth-bot · 2024-05-13T05:00:50Z

✅ All reviewers have approved.

EIPS/eip-4762.md

gabrocheleau · 2024-05-17T13:27:08Z

EIPS/eip-6800.md

-| VERSION_LEAF_KEY | 0 |
-| BALANCE_LEAF_KEY | 1 |
-| NONCE_LEAF_KEY | 2 |
+| BASIC_DATA_LEAF_KEY | 0 |
 | CODE_KECCAK_LEAF_KEY | 3 |


Should we update CODE_KECCAK_LEAF_KEY to 1 instead of leaving 1 and 2 empty?

EIPS/eip-6800.md

g11tech · 2024-05-17T14:36:04Z

EIPS/eip-4762.md

 ```
-(address, 0, BALANCE_LEAF_KEY)
+(address, 0, CODE_HASH_LEAF_KEY)


so we need to remove isEmpty check?
or we assume that if codehash witness is non null then it isn't empty? and for empty accounts it will come null

Q: are we writing the keccak(null) when EOA account is added to state for the first time?
(UPDATE: realized answer is that: a new EOA account will always have be a target of the tx and the tx accesses will add codehash access/data to the state)

so i guess based on the witness being null or not null we can decide the extcodehash is the provided one or 0

Lateral question: the consensus wasn't that we still would have to touch "VERSION" to be forward-compatible? If that's the case, we also need to add here BASIC_DATA_LEAF_KEY which can simplify all the questions above (since it comes with all the rest)?

EIPS/eip-4762.md

g11tech · 2024-05-17T14:54:15Z

EIPS/eip-4762.md

@@ -268,6 +254,13 @@ class AccessSubtree(Container):
 elements: BitVector[256]
 ```

+## Block-level operations
+
+* Precompile accounts, system contract accounts and slots of a system contract that are accessed during a system call are considered warm.


just to reconfirm this is only for the system call?

also system call is:
i) system updates not related to a tx
ii) a precompile executing system call code (blockhash)

system calls, right now, are 2935 (post osaka), 4788 and 7002. whatever stuff they use that get accessed, should be considered warm.

I am actually close to reconsidering that, it's a special case.

I would like to distinguish between system call and system update.

i) system update is the client book keeping i.e. not related to the tx, in 2935 for e.g. writing the parent hash of the current block before tx execution begins. exits collection from 7002 is also a system update in those terms that happen post tx execution. withdrawals is also a system update in that sense.

ii) system call is for e.g. BLOCKHASH doing the accesses via evm or directly.

I think you mean system update here to warm (so only those which happen before txs execution actually matter since only they can impact cost)

Post-Osaka-2935 has a long history. I'm not sure accesses to that history via the system contract should be considered warm?

By "warm" we mean potentially adding it to the witness at a subsidized cost?

@g11tech reg your last paragraph, system updates from my perspective doesn't make sense to say are cold or warm, since we can't charge anyone for that?

reg your last paragraph, system updates from my perspective doesn't make sense to say are cold or warm, since we can't charge anyone for that?

yes I mean whateever system updates access warms for the txs. With this logic only the last entry in the ring buffer would be warmed and others cold so not the rest 8191 hashes

g11tech · 2024-05-17T14:58:10Z

EIPS/eip-4762.md

+## Block-level operations
+
+* Precompile accounts, system contract accounts and slots of a system contract that are accessed during a system call are considered warm.
+* When (and only when) calling a system contract _via a system call_, the code chunks and account should not appear in the witness.


this implies that stateless clients need to maintain system contracts . Also there is an unresolved issue of stateless clients not knowing if the contract has been actually deployed or not.

we should simply declare that stateless clients should assume activated system contracts deployed.

this implies that stateless clients need to maintain system contracts

it does not: because there is no obligation to call the contract's EVM, you are free to write the storage slots directly without having a local copy of the code.

Also there is an unresolved issue of stateless clients not knowing if the contract has been actually deployed or not.

I also don't see why this would be true. System contract activation is part of the pectra fork, so it should assume that.

we should simply declare that stateless clients should assume activated system contracts deployed.

indeed. Or do you mean that it should be in the spec itself?

because there is no obligation to call the contract's EVM, you are free to write the storage slots directly without having a local copy of the code

for system contracts like 7002, even stateless focused clients like ethereumjs just does the EVM call to get the triggered exits contract to get the exits. But this isn't a deal breaker just something clients need to bundle in verkle.

System contract activation is part of the pectra fork

deployment is a manual exercise and not really part of client hardfork (that clients deploy this contract on forkblock which imo should have been a better mechanism to deploy the tx if not already deployed). I mean I already had done the mistake of not adding a contract in a local testnet and then debugging why things weren't working. So I would like things foolproof if possible. The problem could become acute as the number of such contracts grow.

indeed. Or do you mean that it should be in the spec itself?

yes a simple mention of this would clearup the "ruleset" for the stateless client.

g11tech · 2024-05-17T14:59:06Z

EIPS/eip-4762.md

+
+* Precompile accounts, system contract accounts and slots of a system contract that are accessed during a system call are considered warm.
+* When (and only when) calling a system contract _via a system call_, the code chunks and account should not appear in the witness.
+* The coinbase account is warmed before the block, and the whole account is accessed


whole account = basic data + code hash? and 2929 warm cost if accessed in a tx?

this is because the coinbase might not exist, so to avoid a lot of issues, we decide to touch the whole account so that it's created if it doesn't exist already.

what if there is no tx that puts any value to it, and lets say there is no tips that get added to a non existent coinbase, then it should be 158 cleaned up in the end of block?

is warmed before the block

"before the block" is maybe confusing?

What about:

The coinbase account basic data and code hash is accessed before transaction execution, and considered warm for all txs.

jsign · 2024-05-17T14:59:20Z

EIPS/eip-4762.md

 ```
-(address, 0, BALANCE_LEAF_KEY)
+(address, 0, CODE_HASH_LEAF_KEY)


In 4762 we have mixed namings with CODE_HASH_LEAF_KEY and CODEHASH_LEAF_KEY.
And in 6800 we use CODE_KECCAK_LEAF_KEY.

I'd say to change everything to CODE_HASH_LEAF_KEY or CODEHASH_LEAF_KEY.

I think the big deciding factor is: when ethereum completes its shift to sha256 as its primary hash function (or even moves to something more stark-friendly), would this still be the keccak, or would it change (even if for new contracts or EOF only)? If still keccak, then call it CODE_KECCAK, if not, call it CODE_HASH.

tanishqjasoria · 2024-05-17T14:49:55Z

EIPS/eip-4762.md

-(address, 0, CODE_SIZE_LEAF_KEY)
-```
+ 1. a non-precompile address is the target of a `CALL`, `CALLCODE`, `DELEGATECALL`, `STATICALL`, `AUTHCALL`, `SELFDESTRUCT`, `EXTCODESIZE`, or `EXTCODECOPY` opcode, 
+ 2. a non-precompile address is the target address of a contract creation whose initcode starts execution,


i think this is covered below?
https://github.com/ethereum/EIPs/pull/8550/files#diff-cd2aaa222faeb6081a41605386a509b3c4839285cd15f1b0ebe009318707914eR126

tanishqjasoria · 2024-05-17T14:51:49Z

EIPS/eip-4762.md

 ```

-If the `SELFDESTRUCT` opcode is called by some caller_address targeting some target_address (regardless of whether it’s value-bearing or not), process access events of the form:
+When a contract is created, process these access events:


i think this is also duplicated - https://github.com/ethereum/EIPs/pull/8550/files#diff-cd2aaa222faeb6081a41605386a509b3c4839285cd15f1b0ebe009318707914eL143

tanishqjasoria · 2024-05-17T14:53:28Z

EIPS/eip-4762.md

+`CREATE*` and `*CALL` reserve 1/64th of the gas before the nested execution. Note that, following the behavior of access lists, the 1/64th of the gas is subtracted:
+
+ * **BEFORE** charging the witness costs when performing a `CALL`, `CODECALL`, `DELEGATECALL` or`STATICCALL`
+ * **AFTER** charging th witness costs when performing a `CREATE` or `CREATE2`


we also clarify that the contract creation complete gas cost should be charged before adding the 1/64 gas after the creation is completed.

tanishqjasoria · 2024-05-17T15:07:34Z

EIPS/eip-4762.md

@@ -268,6 +254,13 @@ class AccessSubtree(Container):
 elements: BitVector[256]
 ```

+## Block-level operations
+
+* Precompile accounts, system contract accounts and slots of a system contract that are accessed during a system call are considered warm.


should we add that the code chunks during system calls are not to be warmed? or it might cause additional confusion?

system calls totally ignore code chunks imo both for accesses and gas compute and we can clearly mention it to remove confusion

tanishqjasoria · 2024-05-17T15:12:26Z

EIPS/eip-4762.md

+* Precompile accounts, system contract accounts and slots of a system contract that are accessed during a system call are considered warm.
+* When (and only when) calling a system contract _via a system call_, the code chunks and account should not appear in the witness.
+* The coinbase account is warmed before the block, and the whole account is accessed
+* Withdrawals are cold, but are added to the witness at no cost if they are the target of a transaction.


we should add the clarification about storage cells here.
If in a trasnaction, storage value is set and then reset to zero, we should insert zero to the tree and not leave it empty because the user paid the gas cost.
Basically if we charge CHUNK_FILL_COST, fill the chunk value.

lateral question/observation to the above:

this is just because withdrawals are processed at the end of the block, and there is no actual cost charged to the coinbase for processing them?

I raised a similar confusion yesterday to Guillaume about this line.

but are added to the witness at no cost ...

seems to imply there're a case where they're added at a cost; but who is paying that cost?

If the idea is that withdrawals never pay a cost, from my perspective clarifying they're "cold" (as mentioned in the first words in the sentence) is confusing.

EIPS/eip-4762.md

jsign · 2024-05-17T19:22:03Z

EIPS/eip-4762.md


 ```
-(address, 0, CODEHASH_LEAF_KEY)
+(caller_address, 0, BASIC_DATA_LEAF_KEY)


If this rule applies if it's value-bearing or not, and for all cases (i.e: including precompiles), I think we might be able to remove SELFDESTRUCT from this rule?

jsign · 2024-05-17T19:23:41Z

EIPS/eip-4762.md

+(caller_address, 0, BASIC_DATA_LEAF_KEY)
+(target_address, 0, BASIC_DATA_LEAF_KEY)


So, isn't this L74-L78 rule more general than this one for SELFDESTRUCT?

If that's the case, we could remove SELFDESTRUCT mentioned in that linked rule, and only leave this L74-L78?

I'm starting to feel if wouldn't be easier for everyone to simply list rules for each independent instruction. Like *CALL, SELFDESTRUCT, etc, instead of trying to coalesce overlaps and re-clarify later with further rules some accessed extensions.

Yes, separating rules by instructions might have some redundancy but for implementors and testing it will be entirely clear what to do for each instruction. Now you have to read the whole document to see if in an extra scenario the same instruction you're interested in has another rule (i.e: value bearing? is or isn't precompile? etc).

cc @gballet @g11tech @tanishqjasoria

yes, i kind of agree with this. Listing every opCode seperately will be a better idea.
Right now its much easier to miss something.

in EIP its good to be concise, in the execution specs we should do independently (or have some assets attached)

jsign · 2024-05-17T19:30:15Z

EIPS/eip-4762.md

@@ -123,31 +119,21 @@ We define **write events** as follows. Note that when a write takes place, an ac
 When a nonzero-balance-sending `CALL` or `SELFDESTRUCT` with a given sender and recipient takes place, process these write events:


Should say *CALL?

jsign · 2024-05-17T19:31:29Z

EIPS/eip-4762.md

-(contract_address, 0, BALANCE_LEAF_KEY)
-(contract_address, 0, CODE_KECCAK_LEAF_KEY)
-(contract_address, 0, CODE_SIZE_LEAF_KEY)
+(contract_address, 0, BASIC_DATA_LEAF_KEY)


Is this line needed given that L126 does the same write-access and initialized < created?

EIPS/eip-4762.md

jsign · 2024-05-17T19:34:36Z

EIPS/eip-4762.md

+
+`CREATE*` and `*CALL` reserve 1/64th of the gas before the nested execution. Note that, following the behavior of access lists, the 1/64th of the gas is subtracted:
+
+ * **BEFORE** charging the witness costs when performing a `CALL`, `CODECALL`, `DELEGATECALL` or`STATICCALL`


Want to use *CALL to also contemplate AUTHCALL? (Also note a missing space after or)

jsign · 2024-05-17T19:34:58Z

EIPS/eip-4762.md

+`CREATE*` and `*CALL` reserve 1/64th of the gas before the nested execution. Note that, following the behavior of access lists, the 1/64th of the gas is subtracted:
+
+ * **BEFORE** charging the witness costs when performing a `CALL`, `CODECALL`, `DELEGATECALL` or`STATICCALL`
+ * **AFTER** charging th witness costs when performing a `CREATE` or `CREATE2`


Suggested change

* **AFTER** charging th witness costs when performing a `CREATE` or `CREATE2`

* **AFTER** charging the witness costs when performing a `CREATE` or `CREATE2`

jsign · 2024-05-17T19:39:13Z

EIPS/eip-4762.md

-|`CHUNK_EDIT_COST` |500|
-|`CHUNK_FILL_COST` |6200|
+|`CHUNK_EDIT_COST`  |500|
+|`CHUNK_FILL_COST`  |6200|


I can't add this comment in the intended line because there wasn't a change there.
I'm referring to lines L218-L220 and L226.

The intention in both places to say "skip it" is for gas cost charging. But the thing being skipped is also adding it to the underlying access list that are used for the witness creation. If those things also skip adding them to the list, then I think the witness wouldn't be correct?

but the adding of stuff in the access list is done in previous sections, whereas this is specific to the charging of costs.

tanishqjasoria · 2024-05-20T16:09:34Z

i think we should add a section explaing that the account and storage slots that are warmed at the block level should be treated warm for all the transactions. For eg, coinbase and blockhash contract

github-actions · 2024-05-22T11:52:41Z

The commit 508f0ab (as a parent of 1a9afe2) contains errors.
Please inspect the Run Summary for details.

Co-authored-by: Ignacio Hagopian <[email protected]>

g11tech · 2024-05-24T07:54:11Z

EIPS/eip-6800.md

+
+Bytes `1..3` are reserved for future use.
+
+When any account header field is set, the `version` field is also set to zero. The `code_keccak` and `code_size` fields are set upon contract or EoA creation.


should we also add a section about 7702 (eoa temporary contract code) accesses?

In this PR already added rules for AUTHCALL. So mentioning 7702 would be confusing?

Maybe it's better to not yet assume 3074 nor 7702 in any part of the PR (i.e: remove the existing AUTHCALL mentioning) and add a TODO saying Add 7702/3074 to the spec.

jsign · 2024-05-29T12:35:49Z

EIPS/eip-4762.md

 ```

-If the `BALANCE` opcode is called targeting some address, process this access event:
+When calling `EXTCODEHASH`, process the access event:


@gballet, I think we should add here "if the target isn't a precompile".

jsign · 2024-05-30T20:37:20Z

EIPS/eip-4762.md

+
+`CREATE*` and `*CALL` reserve 1/64th of the gas before the nested execution. In order to match the behavior of this charge with the pre-fork behavior of access lists: 
+
+ * this 1/64th of the gas is subtracted **AFTER** charging the witness costs when performing a `CALL`, `CODECALL`, `DELEGATECALL` or`STATICCALL`


@gballet , nit: in the case of *CALL (compared to CREATE*) it isn't a strict reservation, but a "cap check" of the max amount of gas you can use.

If the *CALL parameter provided a gas parameter that is less 63/64, then less gas is reserved (i.e: more than 1/64 is leftover).

Suggested change

* this 1/64th of the gas is subtracted **AFTER** charging the witness costs when performing a `CALL`, `CODECALL`, `DELEGATECALL` or`STATICCALL`

* this minimum 1/64th gas reservation is checked **AFTER** charging the witness costs when performing a `CALL`, `CODECALL`, `DELEGATECALL` or`STATICCALL`

Anyone reading the spec as it's today will understand the important clarification being made here. So I'm fine if we dismiss this nit.

jsign · 2024-05-30T20:46:33Z

EIPS/eip-4762.md

+
+`CREATE*` and `*CALL` reserve 1/64th of the gas before the nested execution. In order to match the behavior of this charge with the pre-fork behavior of access lists: 
+
+ * this 1/64th of the gas is subtracted **AFTER** charging the witness costs when performing a `CALL`, `CODECALL`, `DELEGATECALL` or`STATICCALL`


@gballet, I wonder if we're missing an extra clarification here.

The *CALL variants that can be value-bearing, should also respect this rule?

Today in geth, we have this order (e.g: makeCallVariantGasEIP4762(gasCall)):

Charge general *CALL costs. (inside makeCallVariantGasEIP4762(...))

Do the 1/64 stuff (inside gasCall(...))

Charge BALANCE if transfersValue (inside gasCall(...))

So I'm wondering if this requires a clarification, or was intentional. If was intentional it means that today in kaustinenv6-geth we need a change.

reworked gas schedule from interop

a8cfb56

github-actions bot added c-update Modifies an existing proposal s-draft This EIP is a Draft t-core labels May 13, 2024

eth-bot changed the title ~~reworked gas schedule from interop~~ Update EIP-4762: reworked gas schedule from interop May 13, 2024

github-actions bot added the w-ci Waiting on CI to pass label May 13, 2024

gballet added 2 commits May 14, 2024 16:30

replace account leaves with "basic data"

06b7248

first pass on the interop feedback

acec5e6

gballet commented May 17, 2024

View reviewed changes

EIPS/eip-4762.md Show resolved Hide resolved

all remaining changes, save warming and precompiles

2e609fd

gabrocheleau reviewed May 17, 2024

View reviewed changes

EIPS/eip-4762.md Show resolved Hide resolved

gabrocheleau mentioned this pull request May 17, 2024

client: kaustinen7 verkle testnet preparation ethereumjs/ethereumjs-monorepo#3433

Draft

4 tasks

gabrocheleau reviewed May 17, 2024

View reviewed changes

gballet commented May 17, 2024

View reviewed changes

EIPS/eip-6800.md Outdated Show resolved Hide resolved

Update EIPS/eip-6800.md

7af9770

jsign mentioned this pull request May 17, 2024

Update EIP-6800: pack basic data in a single sub-index vector entry #8576

Closed

jsign reviewed May 17, 2024

View reviewed changes

EIPS/eip-6800.md Outdated Show resolved Hide resolved

gballet changed the title ~~Update EIP-4762: reworked gas schedule from interop~~ Update EIP-4762/EIP-6800: reworked gas schedule from interop May 17, 2024

add missing info

271a9e4

eth-bot changed the title ~~Update EIP-4762/EIP-6800: reworked gas schedule from interop~~ Update EIP-4762: reworked gas schedule from interop May 17, 2024

github-actions bot added w-ci Waiting on CI to pass and removed w-ci Waiting on CI to pass labels May 17, 2024

g11tech reviewed May 17, 2024

View reviewed changes

EIPS/eip-4762.md Show resolved Hide resolved

g11tech reviewed May 17, 2024

View reviewed changes

jsign reviewed May 17, 2024

View reviewed changes

tanishqjasoria suggested changes May 17, 2024

View reviewed changes

jsign reviewed May 17, 2024

View reviewed changes

EIPS/eip-4762.md Show resolved Hide resolved

jsign reviewed May 17, 2024

View reviewed changes

EIPS/eip-4762.md Outdated Show resolved Hide resolved

jsign reviewed May 17, 2024

View reviewed changes

EIPS/eip-4762.md Outdated Show resolved Hide resolved

jsign reviewed May 17, 2024

View reviewed changes

EIPS/eip-4762.md Outdated Show resolved Hide resolved

jsign reviewed May 17, 2024

View reviewed changes

integrate Vitalik's feedback

508f0ab

fix formatting issues

ea647e7

github-actions bot removed the w-ci Waiting on CI to pass label May 22, 2024

Mortiemi mentioned this pull request May 22, 2024

The commit 508f0ab9c22411777c949909127d147beff34158 (as a parent of 1a9afe2dca9a2f0584487084e29667f591f6628c) contains errors. MetaMask/contract-metadata#1307

Open

gballet and others added 2 commits May 22, 2024 14:43

Apply suggestions from code review

96e3281

Co-authored-by: Ignacio Hagopian <[email protected]>

more formatting fixes

29da746

g11tech reviewed May 24, 2024

View reviewed changes

jsign reviewed May 29, 2024

View reviewed changes

jsign reviewed May 30, 2024

View reviewed changes

		(caller_address, 0, BASIC_DATA_LEAF_KEY)
		(target_address, 0, BASIC_DATA_LEAF_KEY)

		@@ -123,31 +119,21 @@ We define write events as follows. Note that when a write takes place, an ac
		When a nonzero-balance-sending `CALL` or `SELFDESTRUCT` with a given sender and recipient takes place, process these write events:


		`CREATE` and `CALL` reserve 1/64th of the gas before the nested execution. Note that, following the behavior of access lists, the 1/64th of the gas is subtracted:

		* BEFORE charging the witness costs when performing a `CALL`, `CODECALL`, `DELEGATECALL` or`STATICCALL`

	* AFTER charging th witness costs when performing a `CREATE` or `CREATE2`
	* AFTER charging the witness costs when performing a `CREATE` or `CREATE2`


		Bytes `1..3` are reserved for future use.

		When any account header field is set, the `version` field is also set to zero. The `code_keccak` and `code_size` fields are set upon contract or EoA creation.


		`CREATE` and `CALL` reserve 1/64th of the gas before the nested execution. In order to match the behavior of this charge with the pre-fork behavior of access lists:

		* this 1/64th of the gas is subtracted AFTER charging the witness costs when performing a `CALL`, `CODECALL`, `DELEGATECALL` or`STATICCALL`

	* this 1/64th of the gas is subtracted AFTER charging the witness costs when performing a `CALL`, `CODECALL`, `DELEGATECALL` or`STATICCALL`
	* this minimum 1/64th gas reservation is checked AFTER charging the witness costs when performing a `CALL`, `CODECALL`, `DELEGATECALL` or`STATICCALL`

Update EIP-4762: reworked gas schedule from interop #8550

Are you sure you want to change the base?

Update EIP-4762: reworked gas schedule from interop #8550

Conversation

gballet commented May 13, 2024 • edited

eth-bot commented May 13, 2024 • edited

Choose a reason for hiding this comment

g11tech May 17, 2024 • edited

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

jsign May 24, 2024 • edited

Choose a reason for hiding this comment

jsign May 24, 2024 • edited

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

g11tech May 17, 2024 • edited

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

jsign May 24, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jsign May 17, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

g11tech May 21, 2024 • edited

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

tanishqjasoria commented May 20, 2024

github-actions bot commented May 22, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jsign May 30, 2024 • edited

Choose a reason for hiding this comment

jsign May 30, 2024 • edited

Choose a reason for hiding this comment

gballet commented May 13, 2024 •

edited

eth-bot commented May 13, 2024 •

edited

g11tech May 17, 2024 •

edited

jsign May 24, 2024 •

edited

jsign May 24, 2024 •

edited

g11tech May 17, 2024 •

edited

jsign May 24, 2024 •

edited

jsign May 17, 2024 •

edited

g11tech May 21, 2024 •

edited

jsign May 30, 2024 •

edited

jsign May 30, 2024 •

edited