Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Architecture? #508

Open
hmijail opened this issue Jan 8, 2023 · 9 comments
Open

Architecture? #508

hmijail opened this issue Jan 8, 2023 · 9 comments

Comments

@hmijail
Copy link
Member

hmijail commented Jan 8, 2023

The ARCHITECTURE.md doc needs a revision, and I'd suggest that we should find something more informative than "hi", "mid" and "low" layers. (unless that's some kind of standard that I'm missing?)

It might be useful to put things in terms of the discussion of "EVM equivalence". 
I suspect that the "high layer" is actually the Execution layer, and the "mid layer" is the actual EVM.
https://ethereum-magicians.org/t/evm-equivalence-eip-6269-and-ethereum-stack-compatibility-definition/10044/9

@hmijail
Copy link
Member Author

hmijail commented Jan 8, 2023

Also, ARCHITECTURE.md (why is it in caps?) includes a graph but AFAICT the repo doesn't include whatever is necessary to rebuild it.

@DavePearce
Copy link
Collaborator

Well, I agree the ARCHITECTURE.md can be improved. There's a lot more we could say here, including some stuff already written in the long version of the FM paper.

Also agree that we could consider other terminology instead of "high", "mid", "low", etc. But, this is really an internal description that is not connected (as far as I'm aware) with anything external. Everything is really just the EVM itself. I don't think we have much (if anything) specific for the execution layer. Perhaps some things on the Java side? However, if there is some useful terminology, that would be nice.

@DavePearce
Copy link
Collaborator

Also, ARCHITECTURE.md (why is it in caps?)

Well, just following conventions. Like, e.g. README.md and CONTRIBUTORS.md, etc.

@DavePearce
Copy link
Collaborator

includes a graph but AFAICT the repo doesn't include whatever is necessary to rebuild it.

So, its an an xfig file (.fig extension). We could include that I guess. Maybe there is some preferred format though? Xfig is ... old. And, I tend to use it when writing papers ... but only because I've been doing that for the last 20 years :)

@hmijail
Copy link
Member Author

hmijail commented Jan 9, 2023

The ALLCAPS naming is a Unix vestige/tradition in basic root-of-repo files like README, INSTALL, CONTRIBUTORS, etc. Not sure it makes sense to use it for other random files (which probably should go into a docs/ directory or similar?)

@DavePearce
Copy link
Collaborator

DavePearce commented Jan 9, 2023

Exactly. I wouldn't consider it a random file though. See e.g. here and here.

But, there are examples where its non-caps. I'm not super bothered, but that's my general style.

@hmijail
Copy link
Member Author

hmijail commented Jan 9, 2023

Link 2 is just a recap of link 1, so both give the same single example. 🤔
And then we have SEMANTICS, etc...

@DavePearce
Copy link
Collaborator

I'm sure I can find more examples easily enough. I think its fine as is. As long as we're consistent, then no problem. Anything ending in .md is in caps ... easy.

@DavePearce
Copy link
Collaborator

Randomly, I've just been reading the KEVM paper (which I should have done before now) and noticed it splits into three levels:

KFrameworkLevels

I'd say our high level is similar to their evm.k level, and perhaps our mid and low levels compare to their data.k level. In some sense, our low level is just a bunch of utils really.

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

No branches or pull requests

2 participants