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

OMO: Operating system for Multichain Optimistic rollup with fraud proofs #60

Open
steelgeek091 opened this issue Apr 25, 2023 · 3 comments
Assignees

Comments

@steelgeek091
Copy link
Collaborator

OMO: Operating system for Multichain Optimistic rollup with fraud proofs

A compatibility layer is added on the basis of OMO to act as a bridge between the system and the user's executable program (VM). It is compiled together with the user's executable program in the form of an SDK to shield the differences in system calls, memory allocation and other characteristics in various programming languages and application programs.

@yng17b
Copy link
Contributor

yng17b commented Jul 30, 2023

@steelgeek091 Does this method necessitate modifications to the application code?

e.g.

Employing omo_sdk.file_open to open a file in lieu of the traditional open method which wrap glibc in stdlib.

I wonder if that's true, how about 3rd lib used in users codes?

@templexxx
Copy link
Collaborator

@yng17b

When employing this approach, we are obliged to impose certain restrictions on the application, as this is tantamount to reconstructing an operating system. @steelgeek091 What's ur suggestion?

@steelgeek091
Copy link
Collaborator Author

steelgeek091 commented Aug 2, 2023

@yng17b Thank you for raising the question.

The glibc or other C runtime libraries are typically bundled with the operating system in most cases. For languages like C/C++/Rust, they use the compiler toolchain to link against the C runtime library during the compilation process.
Our work involves linking our own SDK as the C runtime library during the linking phase of the compilation process. Alternatively, we intercept and modify system call access during runtime.

Users typically rely on third-party libraries that also depend on the C runtime library. We can achieve the same functionality for these libraries as well.

These two approaches are applicable to different languages and will be chosen based on the specific scenario.

In summary, we will not require users to modify their way of accessing system calls.

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

3 participants