OMO: Operating system for Multichain Optimistic rollup with fraud proofs

[steelgeek091]

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.

[ghost]

@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]

@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]

@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.