Beyond hardware: Moore’s law is now spilling over into the software within
For decades since its inception, Moore’s law was something associated with hardware—that the number of transistors per silicon chip doubles every year, resulting in exponentially increasing computing power within—conversely—perpetually shrinking components.
But an interview with two of æternity blockchain’s seasoned developers reveals this trend is quickly spilling over into the software arena—one that is poised to be among programmers’ major weapons in tackling blockchain technology’s infamous scaling dilemma.
Running extensive research and tests for æternity is Erlang and Scala veteran Dr. Erik Stenman, who holds a computer science doctorate and has worked with virtual machines (VM) for several years. He’s been programming since 1980.
Recently, Dr. Stenman published a protocol update for the æternity blockchain on Github, called FATE—the Fast æternity Transaction Engine. Dr. Stenman was kind enough to grace us with a quick chat to help us better understand what FATE is.
“Typed virtual machine or engine, we call it,” Dr. Stenman begins. “It’s built on the level of transactions that exist on the æternity system so you can do the kind of things that are built into æternity like Oracles, namespaces, state channels, and so on.”
“The instructions on the machine are on a higher level. There is no memory management on the machine level. It has more advanced data structures like lists, maps, and variant types,” Dr. Stenman continues. “So it’s a simple-to-use machine language which is closer to the actual things you want to do on the chain than the more traditional byte-code virtual machine.”
Easier, safer coding
To put this into a context most people can relate to, Dr. Stenman cites a comparison with the most familiar virtual machine in the blockchain sphere: the Ethereum Virtual Machine (EVM). According to Dr. Stenman, FATE solves a fundamental problem programmers run into when coding for Ethereum, and ultimately makes a safer coding platform for smart contracts.
“With the EVM, there’s the problem that you can run into negative numbers when you increase into large numbers—they suddenly turn into negative numbers. And this is something that has caused a lot of problems, so everyone is using this safe math library to keep numbers from wrapping. But FATE only has integers and they can be of any size, so they will never wrap,” he explains. “So there’s all these things that become simpler and safer with FATE.”
Explaining further, he adds how this minimizes room for error.
“If you have a positive number and you add to it, it will always be positive. It also has a lot of types built in, like maps. And it has type checking so you cannot use an integer for Boolean or Boolean as an integer, for example. In the EVM, everything is just a number. And you can use any number as any other number, even if it’s some other data type. So this will be a lot safer and easier to use through FATE.”
Dr. Stenman explains how FATE is structured differently from the way other virtual machines like Ethereum is.
“In the EVM, a contract is just a piece of code. And you start running it from the start and then it will try to find which function you wanted to use by looking at the data that you send into the code. In FATE, you have actual functions and the functions have types. So, it will start executing at the right function directly, then that function has to match the type.”
For the less technically literate, Nikita Fuchs has a nifty way to explain it. Nikita is a blockchain application developer for æternity—he has worked on several blockchain projects and has conducted blockchain workshops for industry giants like PricewaterhouseCoopers (PwC).
“The way the FATE virtual machine is implemented is, you don’t tell it where to take data and where to put it. You give it an abstract representation of a function,” he says. “It’s like telling your kid to take stuff and put it in some shelves—compared to telling your kid to tidy up a room, and the kid knows what to do. Right now, we’re telling the kid basically to ‘take this box, put it here; take this cup, put it there.’ But with FATE, the virtual machine is able to understand high-level abstract instructions, like how a tidy cupboard is supposed to look like.”
Faster transactions, smaller code size
So what exactly does this mean for people and businesses who use a blockchain platform? Nikita explains how this changes coding as a whole.
“Of course, it takes way less instructions,” Nikita explains. Going back to his kid analogy, he illustrates: “If you tell your kid to tidy up the rooms—where to put every single thing lying around, then you need more instructions.”
In the blockchain sphere, reducing codes and hashes has often been proposed to keep transactions flowing smoothly—and keep a blockchain network from clogging up and freezing everytime network activity spikes up.
“If you represent a smart contract with a huge set of instructions, then of course, the code you need to deploy on our blockchain is way larger, because it has all these instructions. But now, we can just deploy on the blockchain the instruction to, say, ‘tidy up a cupboard.’ We don’t need to tell where to put all the things but the virtual machine knows it so it’s like a higher level of abstraction, so to say. This is important because that does not bloat the chain size so much,” Nikita adds.
Dr. Stenman is optimistic about how much this will improve transaction speeds, although he clarifies that there are still tests to be done.
“Hopefully, smart contracts will be executed faster because you don’t have to marshal a lot between the high-level implementation of the æternity chain itself and the virtual machine—which is very low-level in Ethereum, for example. So there, you have to translate everything into the level of the machine: between the chain and the machine, back and forth—data that is just laid out as bytes,” he says.
“Hopefully, this will result in a lot of contracts being able to run faster. But that’s also something that we will have to measure when we get to the phase of calculating the gas costs for things. So basically, if you’re doing the same kind of work, it will take the same time to run that transaction no matter what chain you’re on. So the question is whether we can get away with less work by being on a high level. And we hope that that’s the case.”
So far, the test they’ve conducted yielded a great result, but both Nikita and Dr. Stenman stay on the conservative side of prediction.
“For example, we did the comparison with a really, really basic smart contract. We were able to save 95% on code size—which is amazing. It’s enormous,” Nikita says. “But we need to do benchmarking first to see how the implications on other aspects in the future will perform—how much faster does this execute in comparison to the basic instructions beforehand?”
Dr. Stenman echoes this stance.
“The byte code for the virtual machine looks like it’s going to be a lot smaller than, for example, Ethereum. I can probably make them arbitrarily much smaller. So let’s say, I tested with a very simple function for Ethereum, a small contract which takes an integer and returns it to you immediately,” Dr. Stenman narrates.
“And it’s pretty huge—around 200 bytes. And that was just ten bytes in the FATE VM. So it’s like at least ten times smaller. But we will see how much smaller it will be with some real contracts. I think it will be a much, much smaller byte code for the same kind of work because you don’t have to say how you push and pop things for memory as you do in Ethereum—and store it in memory, and do things with it.”
“But none of that need to be specified in the FATE VM, so smaller byte code and faster execution, we can hope.”
I noted that even at ten times smaller, it’s actually already impressive, to which Dr. Stenman snickered.
“That’s a sort of a toy program—the identity function that just returns the value that you send in. When you instantiate a contract on EVM, it generates code that it’s going to use the next time. So, the code that you have from the beginning has to contain the code to generate the code that you’re going to run afterward. That makes the initial code a lot larger—and the overhead of that will go down. There’s a huge chunk that you’ll always have on an Ethereum contract which will decrease in size—the ratio of that will decrease for larger contracts. So, I’m not sure we can maintain that level of speed gain or size reduction for larger contracts. Maybe.”
Dr. Stenman explains where they are now and what the estimated timeline is for deploying this on æternity.
“We’re working on it now and we have most of the things in place. The big thing that is missing is calculating the gas cost of everything. If all goes well, it would be in the end of May release, when the next Fortuna version of æternity comes out. Depending on how testing and other things go in April, we will know for sure. And if not, then it will be in the final token burning hard fork—three months after that. but the goal is to get it out in the May release.”
While this is all exciting, Dr. Stenman says we all have to sit tight for a bit.
“No promises yet. We have other work to do and we’ll see how testing goes in April,” he notes.
Amazing article from wearedevelopers.com