What a far more efficient "smart contract" system might look like...

[CIYAM]

If you've read much about Ethereum (other than the hype) then you would know that they (or let's just say Vitalik) invented a VM somewhat similar to Java.

Such JV's were popular back in the 1990's (when I first worked with one) but actually have not been popular in recent times because they are not efficient (hence the rise of VM Ware that is perhaps confused with the other so not surprisingly most people don't know the difference).

What works most efficiently is virtual CPU's (the reason I designed AT the way that it was designed) and the most interesting discovery that I made recently was this: http://www.keystone-engine.org/

This technology could mean that we could use LLVM (a compiler platform that can do C++ and other high-level languages) to do smart contracts (rather than inventing entire new toolsets and high-level languages like Ethereum are doing).

Yes - people could be writing their smart contracts in C++ or even in BASIC - and it wouldn't require a lot of effort.

If you are seriously interested in the tech then I'd suggest you really look into this stuff rather than drink the "koolaid".

[1715352745]

1715352745

[1715352745]

1715352745

[1715352745]

1715352745

[1715352745]

1715352745

[nebuzen]

Very interesting..

This technology could mean that we could use LLVM ..

I would like to understand how the keystone-engine project enables creation of smart-contracts with LLVM.

I always understood smart contracts as DFA's. Contracts that can execute themselves while they continuously check for a clause. Couldn't they be programmed however we like anyway?

Isn't Ethereum just creating a simple and easy platform to program on the blockchain?

I'm sorry if anything I say is wrong, lots to learn!

[CIYAM]

The key thing that is needed in order to have smart contracts that run only a limited number of steps is what is often known as "instrumentation" which is also the thing needed for being able to debug programs step by step.

This is something that Keystone provides - and as LLVM is a well known compiler architecture it would mean you wouldn't need to be using some exotic new language for smart contracts but existing ones (like say C++).

Ethereum's approach is not actually simple at all - instead they have created a Java-like VM for which no tool-base was available and so they have been recreating tools that have been developed for many, many years (re-inventing the wheel).

There is simply no need to be creating new high-level programming languages for smart contracts - the large number of existing high-level languages can do the job perfectly fine (and don't need a whole new set of tools).

[2112]

IMHO not at all an improvement. It is just a translator layer (namely assembler) and it generates just native instructions of CPUs with already existing hardware implementations. Thus it completely lacks execution layer (presumes native hardware execution) and the associated tools like linker & debugger. Good smart contract platform would also have some sort of static analysis tool capable of verifying certain properties of the code to be executed without actually executing it.

I still think that the future optimized Turing-complete cryptographic platform will have special cryptographic instructions and data types. It would be an extension from ALU (Arithmetic-Logic Unit) and FPU (Floating-Point Unit) to perhaps something like CGU (CryptoGraphic Unit). My bet is on something similar to IBM's AS/400, which although introduced in 1988 already had 128-bit addressing. Just narrowly thinking about Bitcoin such a cryptographic platform would have 256-bit registers and addresses with direct support for secp256k1 arithmetic.

[CIYAM]

Thus it completely lacks execution layer (presumes native hardware execution) and the associated tools like linker & debugger.

Please look further into the project I referred to as it absolutely does have the execution layer (its point is to emulate CPUs) with associated tools being supported (via LLVM). Instrumentation is a fundamental requirement here and that is what the project I was referring to provides.

Being able to emulate "real" CPUs means that existing tools can be used (not possible with the approach that Ethereum has taken which is why they have had to spend so much time and money re-inventing the wheel).

It would also make executing such smart contracts possible using real CPUs (assuming the instrumentation part can be efficiently worked out to do this) which is going to be much more realistically achieved by using current hardware rather than hoping for some new future 256 bit register hardware (which I'm not really sure would be of benefit as most non-crypto operations are not going to need 256 bits and future crypto operations would require 512 bits or more).

No doubt this topic is going to get derailed so I will just lock it - for those that are interested I suggest you look into the tech mentioned in the OP.