zink-lang / zink Goto Github PK
View Code? Open in Web Editor NEWRustic programming language that targets the Ethereum Virtual Machine
Home Page: https://docs.zink-lang.org/
License: GNU General Public License v3.0
Rustic programming language that targets the Ethereum Virtual Machine
Home Page: https://docs.zink-lang.org/
License: GNU General Public License v3.0
No response
No response
make WAT code snippets highlighting for easy reading
embed https://rust-lang.github.io/mdBook/format/theme/syntax-highlighting.html while building the book
upload binaries while tagging release
No response
components of #41
comparing with if
, br_if
jumps to labels but not the end of the if-condition block, and loop could be block of branch br_if
targets
No response
For building the backtrace of compilation error
bubble errors from asm generation
We have already addressed all of the bitwise instructions from WASM to EVM bytecdoe, but due the issue for stack orders, they don't work for now, need to fix them and provide tests
No response
Exactly everything required by ERC20 ๐ค
https://github.com/zink-lang/zink/milestone/2
Still far away to complete the MVP instructions of WASM, once we have implemented all of these, we can archive that any WASM program works for EVM.
The main blocker of compiling Zink projects EVM contracts in real world is that that we are currently missing the implementation of memory allocator:
Since EVM uses 32-byte as the basic unit for memory management, we need to implement our own memory allocator to align the compiled memory operations in WASM to EVM, see alloc::GlobalAlloc
This is what we can get directly from the implementation of 1.1
, require tests for custom vector operations.
reference to wasm-ops, complete the MVP instructions,
select
, br_table
, call_indirect
global
related instructionsloadN
, storeN
div
and rem
are not testedTo be a EVM contract : )
The selector implementation is free to go since EVM simply starts from the first byte of EVM binaries which is the main function in general.
The question is that shall we align our selector implementation to solidity?
Guess the answer is yes and no, it is really necessary to adapt the current infrastructure, but, we can do it better with the rust ecosystem, the most simple way to go is that we provide an external function select
or just main
in the compiled WASM, make it the main function, actually a jump table, jumping to specified function by the selector.
The problem needs to be solved is that, how we detect that if the selected function is called as a transaction or just a internal call? requires research on it.
Basically, we need to implement globals to reach this demand, besides, the storage operations require the implementation of host functions since it is out of basic instructions that we can translate from WASM to EVM bytecode.
Events operations are similar to the storage implementation, however, it requires customized types as well.
v0.2.0
ERC20
is reasonable, just do it!
ref: OpenZeppelin/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol
write a script to do it
No response
No response
now we have ek
which is designed for the package manager for zink projects, we need a binary zinkc
just like rustc
compile
in cli/src/compile.rs
cli/bin/zinkc.rs
No response
memory related stuffs are different between dlmalloc ( allocator for WASM in rust ) and EVM
The main blocker of compiling Zink projects EVM contracts in real world is that that we are currently missing the implementation of memory allocator:
Since EVM uses 32-byte as the basic unit for memory management, we need to implement our own memory allocator to align the compiled memory operations in WASM to EVM, see alloc::GlobalAlloc
No response
drop dirty stack items at the end of blocks
No response
No response
i32add | i64add -> add
...
No response
requires the design of the ZOF to call the proper function index, also, JUMP
implementations
No response
Build logs via CI
Need issue templates to format the issues / prs
/.github/ISSUE_TEMPLATE/
/.github/ISSUE_TEMPLATE/config.yml
including examples into the workspace have compilation problems, need to builder outside of target projects to build and post process the wasm output
target/zinc
we only can do static type checks while compiling since the stack item of solidity is 256 bits, so whatever optimize the types or not doesn't matter to EVM, but still needs these types
Need an external library to implement these, mb defined in zink/numbers
for u256
operations, we can use host functions like ("zink", "u256_add")
, etc, do it in EVM for saving space in WASM:
u256::Zero
-> ("zink", "u256_zero")
Inspired by https://eips.ethereum.org/EIPS/eip-3540, here we introduce Zink Object Format
in this project, which makes Zink a common smart contract language for the industry.
ZOF is prepared for the Zink runtime in the future, which at least can execute EVM contract and WASM contract and customized contracts just for Zink.
This library will provide an Intermediate Representation for the zink runtime, WASM parser and EOF parser by default as well
No response
flowchart LR
Body --> Locals
Body --> Operators
we have logic visit operators now but no logic for defining locals
No response
No response
hmmm, for a simple if-else
condition in rust, it will be compiled to select
in WASM directly even though WASM has if-else
...
and this is why we currently not have simple if-else
example, it doesn't work lmao
No response
For the local variables in the main function, we are currently managing it with memory, however, stack is enough, swap, swap, swap
No response
Not sure how to reach this instruction for now, needs research
No response
just follow https://docs.soliditylang.org/en/latest/abi-spec.html
No response
codegen
0.0.0
None
ge
and le
serie of operators are pointing to gt
and lt
incorrectly
like rust developers rarely use rustc
directly, zink users may not use zinkc
a lot as well, since the case is that developers are compiling their whole project to EVM bytecode, and this is the reason why we need elko
For compiling cargo project into evm byteocde with elko
No response
Instructions in 0x96
- 0x9F
( especially for f64
) and same for f32
if exist
No response
https://docs.wasmtime.dev/security.html
(module
(type (;0;) (func (param i64 i64) (result i64)))
(func $add (type 0) (param i64 i64) (result i64)
local.get 1
local.get 0
i64.add))
;; PUSH1 0x10
;; CALLDATALOAD
;; PUSH1 0x20
;; CALLDATALOAD
;; ADD
;; PUSH1 0x00
;; MSTORE8
;; PUSH1 0x10
;; PUSH1 0x00
;; RETURN
both winch and cranelift don't work since they are for register-based target, need to write the compiler on our own now
https://pengowray.github.io/wasm-ops/
need to support all of the MVP instructions to make sure the contracts are able to be totally compiled
there are different cases for this
needs this shadow stack for
No response
u16 <-> usize
and the buffer limit checks are insane
No response
important for promotion
No response
If always converts to jumpi
in solidity,
JUMPI accepts 1 for jump however this is for the end of the if block that we should follow the semantic of if but not JUMPI, append ISZERO
for the JUMPI of if-block, should be solved with #51
No response
we don't have any of them atm, related to #20, to be specific, 0x98
- 0xBF
in WASM instructions
No response
Have a lot of verbose crates due to the original design in the workspace, now we can remove most of them
runtime
-> zink/testing
wasm runtime is in plan, but not now
evm
no need a new evm, will have evm jit in the future, not now
WasmBuilder
to cli/ek
this logic does not belong to the compiler, but a subcommand of cargo tbh
the order for arithmetic operators are different between wasm and evm bytecode, which requires us a swap1
before each of them with 1 more byte and 3 more gas spent
for example: sub
, div
No response
Support local.get
and local.set
, requires refactoring the locals implementation
No response
vercel.json
vercel
No response
wasmtime-environ+ cranelift-wasm will be enough
As the first step of Zink language, parsing functions will just be the most direct way to verify this project
Basic arithmetic operations and stack/memory operations will be enough
EDITED: skip huff and cranelift, to bytecode directly
this.fib
-> fib
No response
The last fragment of the MVP
No response
u8
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.