Writing Smart Contracts in C++

TLDR: if you're just looking for the implementation, skip here. The rest is my rant.

There's a way of making Smart Contracts run at least 10x faster.

Write them in C++.

That's it. That was simple.

Take a look at the example of games. When a game needs to perform, it needs to be written in C++. There is still no way around it.

C++ is known to be an unrivalled language in terms of speed, and arguably, portability, across multiple platforms and architectures.

Well, maybe except for new kid on the block, Rust.

The advantage of using a language like Solidity when writing Smart Contracts is the relative ease of use and implementation. Using a High Level Language allows for shorter development lifecycles, resulting in faster time to market. It's comparatively easy to write and debug, with all the tooling that has been developed around it throughout the last few years.

Yet, the natural maturing of an ecosystem dictates there will be a time, surelly not too far, where speed will cease to be that optional nice-to-have, but instead be a vital or sole requirement throughout the stack, from the bottom up, along all elements of the toolchain.

This was the idea at the base of the popularity of the Rust language, created by Graydon Hoare and supported by Mozilla. First, there was the need for a fast performing language that had some of the characteristics of C++, and then the need arose for that lnguage to be supported by a high performing development toolchain. As the ecosystem continually matures, we're starting to see the results coming in for the last few years - fast performing Rust applications everywhere.

It's the natural evolution of an ecosystem, and the dApp ecosystem will be the same.

And here, compared to Solidity, a language like C++ stands in fact, unmatched.

If one had the ability to write Smart Contracts in C++ and have them be reliably deployed cross-chain, that would be a one-ring-to-rule-them-all event in crypto Smart Contracts, comparable in ambition to industry-wide Project Panama, which interconnects our Java code (or any JVM-compatible code, for that matter) with Native Code, with the significant difference this last effort has Oracle's full financial resource development power behind it. Java Enhancement Proposal details are available on JEP-412 and JEP-414. But as an immediate cherry, the JVM is getting close to full runtime access to TensorFlow's original Native libraries and their associated high performance (of which TF's Python libraries work mostly as wrappers, taking advantage of Native's speed).

Being able to support C++ for writing Smart Contracts is an ambitious vision projected into the future, and while projects in crypto come and go, some more than others show intentionality towards a long-term view of this future.

EOS is and always was a promising project, a Layer-1 being dubbed one of the "Ethereum Killers" from its inception. In reality, it has had an unimpressive performance at all levels - both the token value (it remained a satellite to Bitcoin's price), and the project itself (still has to deliver on the results it's been promising since MainNet pre-launch - higher transaction speeds and the end of gas fees).

It's the most popular ICO ever, lasting for 1 year and raising $4.1B from investors. Yes, that's a "B" for "billion" at the end. No wonder underperformance is bound to be heavily criticised.

To be clear, I own no EOS tokens. Any interest in this is purely technical.

So there's a lot of negative sentiment to deal with coming from the community. Some scream "scam" and "money-grab", and with $4.1B funding, critical voices say the project's ambitious promises will never see the light of day.

Nevertheless, it can make the claim of being one of the greatest platforms for dApps besides Ethereum, unlike many other completely dead or zombied crypto projects. There are centralization critics of what many consider an ability to centralize both by design and in practice, inviting to the creation of financial gangs and cartels, and also critics on its real transaction speed, which has been said to be a fraction of the promised performance - a big selling point while gathering capital from investors. Regardless, markets maintain interest and EOS tokens, though not mineable anymore, can be traded at exchanges.

Interesting. But what can we do with it?

Implementation

Implementation is made using the EOSIO Contract Development Toolkit. Make sure you download it and install it according to instructions.

First things first, you must have created an account hello with permission active. If you haven't done so, please go and do it now. The rest of the instructions won't make much sense if the account hasn't been created. If you need help doing so, there's useful information in the Accounts and Permissions documentation page.

Now, you need to create the directory and cd into it. This part is really necessary, as you'll need the directory name to later deploy the resulting .wasm and .abi files. So:

mkdir hello
cd hello

Next, you should create the source file hello.cpp in your favourite editor with the following content:

#include <eosio/eosio.hpp>

class [[eosio::contract]] hello : public eosio::contract {
  public:
      using eosio::contract::contract;
      [[eosio::action]] void sayhello( eosio::name contractuser ) {
        print( "Hello from EOSIO, ", contractuser);
      }
};

Done? Now compile the source file by invoking the eosio-cpp compiler (note the incantation of the webassembly file as the output):

eosio-cpp -abigen -o hello.wasm hello.cpp

The compilation produces two files, the webassembly containing the binary code that will run, and the .abi file with the Application Binary Interface. Both of these are necessary for us to run the contract.

So, first let's cd out of the project directory:

cd ..

We're ready to deploy its contents. You need to specify account hello with permission active that you created earlier on, remember?

So the deploy command will look something like this:

cleos set contract hello ./hello -p hello@active

And you're done!

Congratulations!

Additionally, you may want to verify the deployment by calling the Smart Contract actions.

This will allow you to push Smart Contract transactions into the blockchain.

Try it like this:

cleos push action hello sayhello '["YourName"]' -p foo@active

As an output, you should have something like this:

executed transaction: ef72b7b070d19329b296f2d933df9e0ffb82564d236d914dac906833564a0d44  244 bytes  1000 cycles
#    hello.code <= hello.code::sayhello               {"user":"foo"}
>> Hello from EOSIO, YourName

Adjust the parameters to fit your case, if you find it necessary.

Try to make sure your wallet is unlocked throughout this procedure. If at any time you experience any problems or can't follow through, that might be one reason. Try to revise your steps carefully, and look into what might have gone wrong. In doubt, try to read up on these resources:

• the Accounts and Permissions documentation page

• the set contract command help information, which you can get to by invoking cleos set contract --help in the CLI

• the Push Action documentation page

That should be enough to get you started.

Simple enough, right?

Try making contracts with authorization, as a next step. With the basics in place, you should be getting into more complex C++ Smart Contracts in no time.

Keep it moving.

How to Develop For The Blockchain

It would be easy to say there's nothing to it, but that wouldn't be true, right?

Blockchain has been one of the great visible technological developments that we've had the chance to witness in the last few years, but it can't be quite considered an easy field, even though many resources now lower the barrier to entry. One of the reasons is that the novelty makes it a moving target in terms of requirements.

So how would one approach blockchain development? The short answer is, you really need to know the ecosystem and then keep up with the changes. There are shortcuts as in any expert field, but in general there's no one-size-fits-all approach. If you're starting an Altcoin, you really need to have a tight plan, but in general you need to know some details about the project you're addressing.

If you're going to program in existing blockchains, knowing where to start gives you a lot of leverage. Languages like C++, Java, Javascript and Python will put you at a big advantage. Bitcoin's core is written in C++, but that will change depending on what project you want to target. For instance, if you plan to work with Ethereum, you'd probably be looking into Dapps and Smart Contracts, maybe Solidity.

Also, you need to know the main algorythms like PoW (Proof of Work), PoSV (Proof-of-Stake-Velocity), DPoS (Delegated Proof-of-Stake), LPoS (Liquid Proof-of-Stake) and BPoS (Bonded Proof-of-Stake). They sound like a mouthfull and can be quite scary at first sight, but once you grasp the needs that drove each one into existence, you'll understand deeply what issues all of them address and the required development of proofing algorithms.

How I Implemented My Own Blockchain Out of BitCoin Code

It's called a fork. It's a copy of the new developments going on in the source code. And you're actually encouraged to do it, in order to get yourself acquainted with the moving pieces and internals of the BitCoin source. The name 'fork' comes from the fact that, from the point that new changes are introduced, the source code splits from the original like the teeth in a fork, that will run in parallel, sharing the same original body.

Some forks are considered aggressive, and these are not at all encouraged, mainly due to the intent underlying them. BitCoin Cash is considered to be an aggressive fork of BitCoin, resulting from a disagreement regarding the block size on the transactions, which impacts the more consequential and utilitarian philosophical question as to whether BitCoin should direct its usage as a store of value or a cash payment system - similar to credit cards. The divergence is not only technical, as there are resulting power struggles in order to be able to attract the most qualified developers to one system or another - doing the code fork is the easy part, implementing a fully functioning network parallel to BitCoin's is a task of epic proportions.

The Open-Source nature of the forking process, in fact encourages anyone to do it. There are many reasons to do so. Like us. One of them is to implement our private blockchain, that will process transactions and generate blocks independently from BitCoin, in our private transaction / payments system.

So here we're not trying to take over the world. Yet. That's Lesson Two.

BitCoin taking center stage makes it easy for everyone to point out its "flaws" and how they would like other features being implemented. So they can do just that, and implement their own forks. Some even question whether Proof-of-Work, the whole base value proposition on BitCoin's network, is required at all. And it might, or might not be, depending on your case. You have to look into it, and find a fork that's close to what you're looking for. Or just fork BTC itself, and put in your changes, if you're going to stay closer to that codebase.

We want some features that can be found in code that derives from BitCoin, while maintaining the same woking fundamentals. LiteCoin is a fork that has much quicker transaction times. Reddcoin, on the other hand, is a fork of LiteCoin, that introduces incentives for actually making the coin circulate, which is called Proof of Stake Velocity (PoSV). So when we fork it, it's actually a fork of a fork of a fork.

It's forks all the way down.

This is the process for creating a new blockchain, based on Reddcoin, a fork of LiteCoin that implements Proof of Stake Velocity as its method of proof, alternativelly to Bitcoin's now questioned Proof of Work. The implementation is done in C++, make, and Bash Shell Script.

We set inputs for the coin such as Target Timespan and Target Spacing, we define parameters relevant to PoSV such as New Stake Minimum and Maximum Age, Last PoW that should be considered, Coin Name, Passphrase, Icons, etc. We apply whatever patches and file replacements are deemed necesssary, and then we compile the full modified source.

The compilation sometimes is local, but many times it's delegated to two EC2 instances - one for the source code of the HOST of the blockchain, and one for the source code of the NODE of the blockchain. They are also responsible for the load of having to do all calculations regarding the Genesis block, Merkle Root, and nonce.

Once they're all found, we have a new blockchain, ready to accept and record our distributed transactions. After all the post-processing, file creation and configuration adjustments, we have access to full binaries of the blockchain, all object files, as well as the daemons and servers' binaries, complete with a wallet in C++ qt, for the graphically inclined.

So what did we do here?

1. We initiated a hard fork of an improvement over Bitcoin's network;
2. We began mining a new chain of transactions;
3. We tweaked technical parameters;
4. We explored possible methods of scaling the network;
5. We explored the fork's operational codes (currently enabled, as well as disabled at the protocol level);
6. And finally, we reprogrammed the original client to use with our new forked chain of transactions.

In our case, we worked with two Amazon AWS EC2 instances for compiling and deploying both client and server, which was a good compromise as the instances were powerful enough to handle the workload imposed by short but intense complilation bursts, and by virtue of the networking between them, also allowed for a constant correct-and-debug approach, flagging errors as soon as they appeared.

In the picture above, on top we see operations in one EC2 instance and another, and the bottom shows resource usage by Linux 'top', in each of those instances.

On the left, you can see the output of the wallet daemon being run, with full information details for the daemon and configured behaviour. There's also summarised information for the wallet, and information relevant to staking the tokens. Remember - BTC has no staking, but we're dealing with PoSV here.

On the right, you can see the code being recompiled after mining the genesis block, which we're injecting at this point, so that the compiled code will have all the new necessary information from this block going forward. In the end, it will generate the code for a full running node, and also a wallet.

So there you have it. You can do it too.

Simple Coin Creation - Now With Powerful Algorithms for PoW and PoSV

And what is the difference, you might ask? Well, the acronym PoW stands for Proof of Work, while PoSV stands for Proof of Stake Velocity. Both are ways of validating transactions and maintaining vigilance over the coin's network , but while PoW is driving Nvidia's chip prices up by using more and more computing power to solve the complex mathematical problems required to confirm transactions, PoSV rewards both the ownership and age of the coin, while also rewarding frequent staking of the coins and users who have very active wallets in the network.

Reddcoin is one of those coins embracing the problems Bitcoin doesn't yet take care of, and may have little incentive to do. In the meantime, the technical evolutions are here to stay.

And in our AltCoin development efforts, we're not standing back. We're supporting PoW and PoSV whenever require. We're adding to the choices and giving a better entry point for anyone who wants to have the latest and greatest technology entry points out there.

Who Would Have Thought - Coin Creation Is Not Easy But We've Automated It To Just a Few Parameters Here and There

It keeps getting better and better!

Not only we offer our Coin Development services, we're now going meta, and automating big parts of the process, just so you can have more flexibility. As the AltCoin world evolves, we evolve and automate with it too.

We've got the coin creation process (the source code modification part of it) automated to about 90 percent! Yup, that's it, you've read it right. That means we can spend more time looking into the specific requirements of your AltCoin, instead of taking care of details that can be automated by preprocessing the C++ code. This means faster delivery times, better detail work, and less errors in the code. We're using a mix of technologies for this and there's still a limited number of coins where where it works, but it keeps evolving day by day, so it's only going to get better.

How is this done, you may ask? Well, it requires a thorough review and analysis of BitCoin's Source Code. That is freely available, you can download it here. Checking out the code and going through the main portions of it is going to give a very good general idea of the main functions and operations being implemented.

Also important, setting up your environment either through an IDE or otherwise, and getting it to a compilable and runnable binaries, is going to give you a pretty good idea of how the compiled deliverables are generated, as well as their functionality.

Then it begins the labourious and iterative part of trying to identify which of the functionalities and parameters offer a point of interest and importance, trying to factor out what input we can change and supply to achieve the desired results.

Not always things go according to plan. But if you set yourself right, you're going to learn along the way, and eventually move through all the functionality that you think it's important.

Much of it can be done with general available READMEs and resources, but having read Mastering Bitcoin" by Andreas M. Antonopoulos has certainly helped along the way, so I would definitely recommend for being value added. I'd also recommend Learning Bitcoin from the Command Line as a valuable resource as it includes many examples and resources if you like the command line and feel good working in that environment.

This process can, of course, be applied to any other AltCoin available out there: LiteCoin, ReddCoin, etc.

Using Blockchain Technology to Build Systems of Accountability and Authorship Compensation

After doing some iterations of AltCoin development, we got in contact with some exciting new ways people around us are embracing the concept of the blockchain, and find new and creative ways to implement it in the products they bring forth.

Sure, everyone knows blockchain is going to have a huge impact in many industries, and it's going to define the future for lots of them, but part of the big question is how do we get from here to that oh-so-bright future. Because to get there, someone's got to implement it, and there's plenty of room for failure along the way. Put it another way, it's easier to be part of the huge pool of failure than to be part of the selected few who succeed. Most important will be resilience, and a solid project is one of the best ways to endure the long walk ahead.

One of the efforts that we've come into contact and deserves a mention is Steemit. It presents a clear proposition - a social networking and blogging site that rewards participants who post, discover and comment content. Not unlike Reddit, but karma is paid in Steem Dollars, one of the platform currencies tradeable for tokens the platform creates, called STEEM. All the content and transactions are tied to the platform's blockchain, which is in itself an interesting concept. By now, they even offer an API in various languages. We've got to play a bit with the Ruby version (screenshot above), and got the impression it's quite handy and supports many operations one would need to build full applications. Bots are many, but we can see this ecosystem evolving into a human/machine hybrid that's totally bound by the blockchain. With its own monetary system and an API for posting content, it's been showing signs of some maturity and maybe it will grow to be one of the long distance runners for this blockchain marathon. Something to keep an eye for, if nothing else for the concept.