BSV as a virtual machine


This week, we’re exploring a few more technical aspects behind Bitcoin BSV and the lesser-known components under the hood that are of more interest to computer science students. We will talk about compilers, byte code and BSV as Computer. So if this is your cup of tea, get dressed, grab your shield and your sword, valiant knight, for we will kill dragons today!

When I was in college, there was a special room in the math building, where the computer science department was located, with an ominous sign above the door that read: “Give up all hope, all of you. who enter here!

It was, of course, the home of the computer club… a bunch of reclusive geeks who have an unhealthy penchant for model trains. In fact, one of the rooms featured a set of giant models, which was part of a fourth year course on real-time operating systems. At the time, I had a general dislike of the locals who frequented this room, partly because they often spoke in a language I couldn’t understand, but mostly because of the unholy smell that permeated its interiors. wet.

What I didn’t know at the time was that the mystical arts practiced inside would be something I would be largely absorbed in, around 25 years later in life… namely, this dark art, computer language compilers. Why are compilers important? Because BSV is a computer. More precisely, it is a virtual machine. In the early days of computing, each CPU had a different instruction set, and compilers had the difficult task of translating high-level computer code into a different form of machine code that was specific to the computer hardware you wanted. that the program is running. . This was largely the reason it was a “dark art” and practitioners who were experts in the field were often referred to as “wizards.” (And rightly so, the earthly low standards of common personal hygiene no longer seemed to concern them).

In recent years, the concept of virtual machine, i.e. a simulated machine, with a common byte code language has been popularized and has greatly simplified the task of compiling the language. Because compilers no longer needed to translate languages ​​into each individual machine code, but just intermediate byte code, which was designed universally enough that specific virtual machine implementations that handled that byte code universal can be run on any specific hardware, eliminating the extra translation task that compilers had to handle.

The most common success case for using a virtual machine can be seen in Java, still the most popular language for developing business applications. More recently, with projects like LLVM and WebAssembly, the idea that languages ​​should be built on an intermediate (or IR) representation, which can then be compiled separately on specific hardware or run directly on a VM has really come to the fore. the power of this model.

So how does Bitcoin fit into all of this? Well, as mentioned, BSV is a virtual machine itself. The nodes that validate transactions on the blockchain all support an instruction set that is Turing finished—As long as there are no theoretical limits on the size of scripts — which means you can program the network to calculate anything that is computable. This bitcoin script can be thought of as the byte code of BSV. And programming for it is a simple task to develop compilers that can transform high level languages ​​into BSV byte code. Some projects like Scrypt are already making great strides in this space.

However, compared to the standard FORTH, the BSV VM byte code lacks several key features (OP codes):

  • OP_CALL or the possibility of passing the execution to subroutines
  • OP_LOOP or the ability to rerun given blocks of code
  • Identifiers
  • Direct memory allocation / access

Without these seemingly essential features of the language, how can the machine be Turing Complete? Well, suffice it to say that these are questions best asked of computer experts, who would no doubt be able to answer these questions more succinctly in terms that would satisfy even the most demanding of experts. I am not one of those people. However, in layman’s terms, each of these features is just a convenience tool rather than an essential requirement for the operation of a general computer. For example: being able to call externally defined subroutines (OP_CALL) can be bypassed by replacing the call with the code of the subroutine itself online.

The need for loopback (OP_LOOP) can be overridden by simply iterating the ad verbatim loop code in the program, with appropriate iteration variables put on the stack, in effect this is the amount of recursive looping implemented under covers. Without the need to call subroutines, identifiers are not needed, as all variables can be replaced with their runtime values, something seasoned FORTH programmers are already used to, as premises are rarely available. , if ever, named.

Finally, the need for direct memory access can be avoided if all temporary storage needs can be met through the use of the main and alternate program stack. Indeed, of the three essential characteristics of structured programming: Sequencing, Selection and Repeat, BSV supports the first two natively and can mimic the third.

Of all the restrictions, the last restricting random access to memory seems to be the most restrictive, as it prevents programs from running in their own temporary sandbox, unable to take advantage of the memory and storage resources of the memory. hardware platform to which they can arrive. work, but that’s actually an advantage, if you consider that you want programs to run universally on a heterogeneous network of machines, from high-powered servers in a data center to small Raspberry Pi, or even on-board devices from weak power .

Forcing this restriction on a program means that all the information that a program needs to access must be provided to it in the transaction in which the program’s UTXO resides, the transaction that “spends” it, which in this case would be more. appropriate to say ‘run it’, which is made possible by smart contract protocols on BSV such as STAS which allow reflection, introspection and the conditions of expenditure imposed on the own exits of the transaction. As we have seen the success of this computational model, over the past decades with browsers and Javascript, the next iteration could be with BSV and Bitcoin compute nodes.

As people begin to realize that Bitcoin is just a new kind of virtual machine, the smarter ones among us will inevitably begin to figure out how to program it efficiently to do useful things. One of the most promising developments in computational models lately is that of MapReduce, or what is sometimes called distributed data-oriented programming. Basically it involves a given function or process that is “mapped” to a large dataset, with a way to collect / aggregate the results from multiple parallel executors. The Bitcoin network, with its number of dynamically adjusting nodes and executors, appears well positioned to operate as a giant pool of compute tasks all ready and willing to execute code on public datasets, producing results. written on the blockchain – for a price, of course.

New to Bitcoin? Discover CoinGeek Bitcoin for beginners section, the ultimate resource guide to learning more about Bitcoin — as originally envisioned by Satoshi Nakamoto — and blockchain.


Source link

Previous Why the skippers are not scuttled | The Economist
Next Riverland Theater and Music announces upcoming fall productions - Albert Lea Tribune

No Comment

Leave a reply

Your email address will not be published. Required fields are marked *