Skip to content

Changes needed to handle CSE#54

Open
nishantjr wants to merge 5 commits intoulmfrom
njr/tweaks-for-cse
Open

Changes needed to handle CSE#54
nishantjr wants to merge 5 commits intoulmfrom
njr/tweaks-for-cse

Conversation

@nishantjr
Copy link
Copy Markdown

No description provided.

nishantjr added 2 commits May 22, 2025 17:07
This is easier for symbolic execution and likely faster as well.
This will likely have a small performance hit, but it will be recovered using CSE.
@nishantjr nishantjr force-pushed the njr/tweaks-for-cse branch from 66a7bd3 to 25679d7 Compare May 27, 2025 05:52
@nishantjr nishantjr marked this pull request as ready for review May 27, 2025 05:52
@nishantjr nishantjr force-pushed the njr/tweaks-for-cse branch from 25679d7 to f0257cd Compare May 27, 2025 05:54
nishantjr added 2 commits May 27, 2025 11:25
During concrete execution these hooks execute to `.K`. This does not work during
symbolic execution, as the side-effects of the hooks would not be accounted for.

In the VLM repo, we have modified the VLM hooks for symbolic execution to instead be
uninterpreted functions that return the WorldState sort.
Here, we create a <worldState> cell to store the side-effects, while unblocking
execution in the <k> cell.
We introduce the ==Bytes construct, because K seems to have difficulty
figuring out that a term of sort K passed reached via executing the semantics
is the same as that introduced via pyk. The reason for this seems related
to the first being parsed as a KSequence, i.e. giveing us `X:Bytes ~> .K`.
I am not sure which is "correct", given the dual nature of the K sort
as the top sort, vs as a sequence.

We also change the requires clause for KZGPOINTEVAL's unhappy path to make it obvious to the backend
that is the negation of that for the happy path.
@nishantjr
Copy link
Copy Markdown
Author

@Robertorosmaninho Sorry, should have mentioned: The individual commits have more information about each change.

Copy link
Copy Markdown

@sskeirik sskeirik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. Thanks!

@Robertorosmaninho
Copy link
Copy Markdown

@nishantjr I left a new comment on our thread

@Robertorosmaninho
Copy link
Copy Markdown

Robertorosmaninho commented Jun 3, 2025

@nishantjr, if your changes are also compatible with op-geth, I don't mind merging them into the ulm branch. However, since our focus is on revm support, and we will now rely on the master branch for our development. Can you please open a PR for this branch against the master branch?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants