Why create a new contract language, solid, instead of using other existing languages

Each programming language is designed for a specific operating environment and target tasks , And these constraints drive almost all design decisions ： What functions are supported and what functions are discarded .

Some time ago , I spent quite a lot of time creating a Go -> EVM Cross compiler . I did manage to run some trivial programs , It's definitely a lot of fun , But soon I began to find EVM The limitation of and Go The core assumptions behind it conflict ：

• Every goroutine All need at least 64KB Of memory . Now , For any decent hardware , Are insignificant low , But for the EVM But it's ridiculously high , The price is also very high .

• Go Depending on the memory manager at the operating system level . It means , To be in EVM Up operation Go Program , We need to be in EVM Develop a micro memory manager based on , To support the Go The required operation . I designed a Buddy Memory Allocation Algorithm POC edition , But the algorithm is based on the case of limited and fixed memory , And allocate any block in it . On the other hand , EVM yes " Infinite " And charge according to the maximum offset of each allocation . therefore , All common memory allocation algorithms will be affected , Because they assume that the memory cost is constant , and EVM It's by position （ Even exponential correlation ）.

• Go It's a garbage collection language , Therefore, each memory allocation also needs to maintain reference counters , This requires good use of memory allocators . It is also not impossible to solve , But the associated opcode and nonlinear memory costs make the overhead very large .

• Even if the memory problem is solved , You still need to synchronize primitives for example 、 Operating system outages and other things we tend to take for granted, but EVM No structure Find a solution .

These challenges are my decision not to continue transplanting Go To EVM The main reason is , But they do show that modern languages are based on countless functions supported by the underlying operating system , These functions themselves are based on assumptions about the underlying hardware capabilities and related costs .

In this regard ,EVM Is very different , Therefore, applying the same assumptions will lead to highly suboptimal code execution . therefore , That's why there's a need to develop a system specifically for EVM The language of the execution environment , It's really possible that more work needs to be done than porting existing language syntax , But it can better produce a usable environment instead of having all kinds of " Limit " Go Code （ Although effective ）.

Also need attention , The original EVM The design can be bad , If someone finds a better solution , It will be expanded , Upgrade or even completely replace . But this is the possibility of the future , and Solidity Is the current need .

Original question and answer link

Block chain in depth - Build a high-quality blockchain technology blog , All the school district chains come here , Focus on You know 、 Microblogging .