solidity

In Oct 2018, we raised $5.6M from Y Combinator, Khosla Ventures and Pantera Capital [6]. We have a backlog of customers waiting to be on-boarded. The team is experienced. This is my 2nd YC startup and I have a PhD in Program Synthesis. The 1st employee was the first hire at Parse (YC S11) and spent 10 yrs at Google. We aim to be a 10-15 person all-engineering team in 2019. Roles/Openings (see [1]): # Software engineer: Systems/infrastructure — You’ll be working on distributing heavy CPU processes on AWS. Making sure processes run reliably over many days. Ensure robustness of the infrastructure across node/process/memory/algorithm failures. # Software engineer: Compilers/verification/synthesis — You’ll be working on developing new algorithms that analyze and generate code [2]. You’ll identify when an engineering solution is needed (i.e., throw across a cluster of machines), or when an algorithmic improvement is required. You might even play with the Z3 theorem prover [3]. And if you’re really into it, you can improve Z3. # Software engineer: Smart contracts — You’ll be working on the “front-end of the compiler”, which reads in smart contracts languages (e.g., Solidity) and makes it accessible to the backend (the part that does semantic analysis). Desire to work at the compiler level of smart contracts is required, e.g., see [4] — experience in writing smart contracts is easily acquired as a side effect. Contact: saurabhs@synthetic-minds.com - Saurabh, Founder [1] Synthetic Minds Jobs: https://synthetic-minds.com/pages/jobs.html [2] Program synthesis: https://medium.com/@vidiborskiy/software-writes-software-pro... [3] Z3 Theorem Prover: https://github.com/Z3Prover/z3 [4] Solidity AST: https://github.com/ethereum/solidity/blob/develop/libsolidit... [5] Solidity smart contracts: https://solidity.readthedocs.io/en/v0.4.21/solidity-by-examp... [6] Forbes funding article: https://www.forbes.com/sites/darrynpollock/2018/10/22/invest...

sufficient compute it can even “synthesize” it. In Oct 2018, we raised a $5.6M seed round from Y Combinator, Khosla Ventures and Pantera Capital [6]. We have paying customers and a backlog waiting to be on-boarded. The team is heavily experienced. This is the founder’s second startup and they have a PhD in the area. The 1st employee was the first hire at Parse (YC S11) and has 10 yrs at Google. We aim to be a 10-15 person all-engineering team in 2019. Roles/Openings (see [1]): # Software engineer: Systems/infrastructure — You’ll be working on distributing heavy CPU processes on AWS. Making sure processes run reliably over many days. Ensure robustness of the infrastructure across node/process/memory/algorithm failures. # Software engineer: Compilers/verification/synthesis — You’ll be working on developing new algorithms that analyze and generate code [2]. You’ll identify when an engineering solution is needed (i.e., throw across a cluster of machines), or when an algorithmic improvement is required. You might even play with the Z3 theorem prover [3]. And if you’re really into it, you can improve Z3. # Software engineer: Smart contracts — You’ll be working on the “front-end of the compiler”, which reads in smart contracts languages (e.g., Solidity) and makes it accessible to the backend (the part that does semantic analysis). Desire to work at the compiler level of smart contracts is required, e.g., see [4] — experience in writing smart contracts is easily acquired as a side effect. Contact: saurabhs@synthetic-minds.com - Saurabh, Founder [1] Synthetic Minds Jobs: https://synthetic-minds.com/pages/jobs.html [2] Program synthesis: https://medium.com/@vidiborskiy/software-writes-software-pro... [3] Z3 Theorem Prover: https://github.com/Z3Prover/z3 [4] Solidity AST: https://github.com/ethereum/solidity/blob/develop/libsolidit... [5] Solidity smart contracts: https://solidity.readthedocs.io/en/v0.4.21/solidity-by-examp... [6] Forbes funding article: https://www.forbes.com/sites/darrynpollock/2018/10/22/invest...

or background https://github.com/ethereum/solidity/issues/164 https://github.com/ethereum/EIPs/pull/211 Also, the longer-term proposal is to adopt WebAssembly for EVM 2.0: https://github.com/ewasm/design. Then users can write contract code using any language with an llvm compiler (rust, ocaml, etc.).

rray. Basics like indexOf() must also be written by hand or implementations copied into your program. To even learn the length of a string you must cast it to a byte array, but see above. In some versions of the Solidity compiler passing an empty string to a function would cause all arguments after that string to be silently corrupted. There is no garbage collector. Dead allocations are never reclaimed, despite the scarcity of available memory space. There is also no manual memory management. Solidity looks superficially like an object oriented language. There is a "this" keyword. However there are actually security-critical differences between "this.setX()" and "setX()" that can cause wrong results: https://github.com/ethereum/solidity/issues/583 Numbers. Despite being intended for financial applications like insurance, floating point is not supported. Integer operations can overflow, despite the underlying operation being interpreted and not implemented in hardware. There is no way to do overflow-checked operations: you need constructs like "require((balanceOf[_to] + _value) >= balanceOf[_to]);" You can return statically sized arrays from functions, but not variably sized arrays. For loops are completely broken. Solidity is meant to look like JavaScript but the literal 0 type-infers to byte, not int. Therefore "for (var i = 0; i < a.length; i ++) { a[i] = i; }" will enter an infinite loop if a[] is longer than 255 elements, because it will wrap around back to zero. This is despite the underlying VM using 256 bits to store this byte. You are just supposed to know this and write "uint" instead of "var". Arrays. Array access syntax looks like C or Java, but array declaration syntax is written backwards: int8[][5] creates 5 dynamic arrays of bytes. Dynamically sized arrays work, in theory, but you cannot create multi-dimensional dynamic arrays. Because "string" is a byte array, that means "string[]" does not work. The compiler is riddled with mis-compilation bugs, many of them security critical. The documentation helpfully includes a list of these bugs .... in JSON. The actual contents of the JSON is of course just strings meant to be read by humans. Here are some summaries of miscompile bugs: In some situations, the optimizer replaces certain numbers in the code with routines that compute different numbers Types shorter than 32 bytes are packed together into the same 32 byte storage slot, but storage writes always write 32 bytes. For some types, the higher order bytes were not cleaned properly, which made it sometimes possible to overwrite a variable in storage when writing to another one. Dynamic allocation of an empty memory array caused an infinite loop and thus an exception Access to array elements for arrays of types with less than 32 bytes did not correctly clean the higher order bits, causing corruption in other array elements. As you can see the decision to build a virtual machine with that is natively 256-bit wide led to a huge number of bugs whereby reads or writes randomly corrupt memory. Solidity/EVM is by far the worst programming environment I have ever encountered. It would be impossible to write even toy programs correctly in this language, yet it is literally called "Solidity" and used to program a financial system that manages hundreds of millions of dollars.