Lamden
Contracting 2 Ideas
There are several ideas to work towards after mainnet and V1 on Contracting. The biggest issue I see is with Contracting is that it is slow, as Python is just slow in general. Yes, we have multiprocessing, but Python is still extremely slow in general and we might not be taking advantage of conflict resolution because of this.
However, because it's in Python, we can add infinite extensions via Python and it will take a few hours versus several weeks. This is the tradeoff.
-
How important is speed? Do we even have any benchmarks of the network usage? Are users feeling that the network is bogged down? How many transactions are generally in the queue of a masternode? Etc.
-
How important is feature development speed? Are people going to want new features ASAP?
Another option would be to introduce a new programming language. This is probably not ideal.
However, for brainstorming purposes, let's assume it is...
LuaJIT is a variant of Lua that has Just-In-Time compilation of the Lua bytecode. It's similar to the PyPy project for Python. Using PyPy for speedups is also an option here, but I'm going to just talk about LuaJIT for illustration purposes.
Lua vs Python in benchmarks can be seen here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/lua-python3.html
A total breakdown of speeds across all languages can be seen here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html
Lua and Python are pretty close to each other, so we can call them 'equivalent.'
LuaJIT vs Lua in benchmarks can be seen here: https://luajit.org/performance_x86.html
Let's assume the numbers are roughly accurate across the spectrum of smart contracts. This would mean that we could get smart contracts running ~27.19x faster per core. Nice!
Problems with this:
- Interfacing with state would require special plugins.
- Python is much more popular than Lua
- Plugins might be harder
Solutions:
- Use PyPy instead
More problems:
- Rewritting the metering functionalities might require core changes to the LuaJIT codebase.
- C programmers are harder to come by and C programming has much higher room for error and is much slower to do.
More solutions:
- PyPy again??