Down the Blockchain As A Service Rabbit Hole

Neo · June 8, 2022, 3:37am

Yesterday I decided to dive into the Blockchain As A Service (BaaS) rabbit hole after finding an April 12, 2022 tutorial by Quick Node on "How to connect to the Ethereum network using Ruby". I thought that since April 12 was less than two months ago, this tutorial would be useful. So, let's start with QuickNode.

QuickNode

QuickNode has both a recent tutorial and a home page code snippet on how to use the ethereum.rb Ruby gem to quickly connect and query the OpenEthereum blockchain. The first thing I noticed was the this ethereum.rb would not compile. Then I noticed the gem was obsolete (and been deprecated) and unsupported. I thought this was "strange', but I pressed on down the rabbit hole.

Not easily discouraged, I decided to fork the ethereum.rb gem to see if I could get it to work; and after making some minor changes, I was able to get a forked version of ethereum.rb to compile. I'm confident in my always-learning Ruby skills and I generally can "fix" most Ruby gem problems (and other Ruby errors), and indeed it was not difficult to get a forked and modified version to compile.

However, I quickly learned that the QuickNode tutorial for ethereum.rb called out using the OpenEthereum blockchain in their console, which was not supported by QuickNode any longer. In fact, the OpenEthereum blockchain had also been deprecated (not directly related to the ethereum.rb deprecation). It seemed my rabbit hole adventure was a plunge into the depths of deprecation!

My thoughts about QuickNode at this point were losing positivity. QuickNode wanted my credit card for a 7 day trial period based on tutorials (dated less than 2 months old and on their home page) based on deprecated code and depreciated blockchains. Not good, I thought; so I fired off a message to QuickNode support. To their credit, they replied quickly and apologized for the deprecated, broken code and offered the eth gem which I was already familiar with. They also requested the URLs of the obsolete tutorials, which was a reasonable request. That was yesterday, and today the QuickNode home page still has the depreciated ethereum.rb gem as their example on their home page.

After experienced this disappointing quality of code samples and service, not to mention the short 7 day trial period requiring my credit card for the privilege of testing their depreciated tutorials, I decided to continue down the BaaS rabbit hole with kaleido, Alchemy and Infura.

To my surprise, I found these BaaS offering less developer friendly than QuickNode. At least QuickNode tried to make Python, Ruby and other API wrappers available for developers with basic code snippets. They tried to actually support developers beyond the lowest level basics. Let's talk about kaleido.

kaleido

Kaliedo looked promising. At least they did not demand a credit card to try their service. However, I quickly learned that their console was too high level, full of way too many screenshots and not enough working code. I quickly became bored clicking away in their console and looking at screengrabs with tiny print (very hard to read) to do things that I have been able to do from the command line (CLI) with blockchains, directly.

However, the "last straw" for me with kaliedo, was the seemingly complete lack of support for Ruby or Python or any higher level programming language at the tutorial level to make getting started very fast. The kaleido API docs were based on curl. This is something we typical see at the "bottom of the barrel" of API docs, so to speak. For example, a "not enough funded" IT team at a bank in a developing country typically might have their API docs based solely on curl. However, for most developed companies with a reasonable IT budget, their API docs go far beyond curl and they will typically have Python libs, Ruby gems, and a lot of other API wrappers based on a developers favorite API. This is how we get started and save time. This is 2022 and every developer is used to having a lot of code to launch from.

After three or four hours down this rabbit hole, I was not "in the mood" to write API wrappers for kaleido yesterday. I have recently written API wrappers in Ruby for Bangkok Bank's currency exchange API and the Satang Pro crypto exchange; but then migrated to Binance and Kucoin where their API wrappers for Ruby (and other languages) are very functional and easy to use and to create apps, fast.

Time is money and precious, and what we want as impatient developers is to not have to write API wrappers for our favorite programming language. That should be done, even if not fully developed, by the API service provider. At least QuickNode, to their credit, tried to support developers in this respectful and thoughtful way. Strange their April 2022 tutorials were based on depreciated code and unsupported chains. Well, at least they "tried". On the other hand, kaleido has seemingly made no attempt, so it seems, to support developers beyond the most crude level of API support, curl. I have written too much low-level API wrapper code over the past two months, and my "well has run dry for API wrapper coding", so to speak. I expected more from a US-based company.

At this point, searching the net for this level of "good API support" from Alchemy and Infura were inconclusive, but not promising, so I decide to take a break from plunging down the blockchain as a service rabbit hole.

Note: I will sync up with Alice and see if she want to go deeper down the BaaS rabbit hole later this week. So far, it's been a disappointing trip.

References:

Neo · June 9, 2022, 2:35am

Have not yet performed enough research on the BaaS providers to offer an informed perspective, other that to be disappointed in the quality of the services offered and concerned about how blockchain as a service has been used by scammers.

Instead of creating solid, well documented blockchain services which add credibility to the blockchain industry, it could be argued that many of the BaaS companies are simply offering quick-and-dirty "blockchain as a service" ways for unethical, or less-than-ethical developers, to create crypto-scams. As I have pointed out many times in the past, college graduates would gladly create the Death Star for the Empire if "Death Star Inc" paid college graduates a high salary. Undoubtably, BaaS providers are providing a mechanism which scammers can use to quickly develop meme coins, fan coins, and other pump-and-dump schemes; however, I have no proof of this possibility.

What I did find, however, was unethical and unprofessional practices in both API documentation and perspective.

For example, one company published a recent tutorial for BaaS and when I pointed out to them what the underlying code and blockchain has been deprecated and obsolete, their response was, and I quote:

"The blockchain space moves blazingly fast, so libraries and tutorials get outdated pretty quickly, and because it moves so fast, we need to make changes to our infrastructure. "

However, the tutorial which I examined was based on technology depreciated a long time ago, much further back in time that the obsolete April 2022 tutorial.

This fact was an unanticipated discovery that I found during my first dive into BaaS, which in my mind gives crypto and blockchain as a service a bad name. Not only do we have scammers pumping their pyramid scheme meme coins at alarming rates, but there are all types of companies providing the underlying technical means for these scammers to launch and operate their chains. The number of BaaS companies which have emerged is staggering, and range from the top tech companies in the world to startups from every corner of the planet.

One could argue that "blockchain as a service" has been a key element to enable "crypto scamming as a service", but it would require a lot more investigation into this domain to prove or disprove this possibility.

In summary, there is no reason to believe that any BaaS company is directly engaged in any wrongdoing with regard to crypto-scams. However, blockchain-as-a-service does raise the question of how many scammers, and their are many in the crypto space, are using BaaS to launch their scams. These BaaS companies appear to be, and are indeed promoted as, a means for the non-technical person to create and manage a blockchain. This begs the questions of "who exactly are using these services?" and "for what coins?" "Where do the scammers go to create a new blockchain?"

In addition, the questionable practice of publishing recently dated tutorials based on long depreciated code and obsolete blockchains is also something I did not expect to encounter on this trip down the rabbit hole with Alice and friends.

Until next time....

Neo · June 10, 2022, 1:13am

I decided to subscribe to the QuickNode monthly plan and "give it a go" and work on a few more tutorials for fun.

The tutorial I decided to test is dated 22 March 2022, "How to create and deploy an ERC20 token"

The first thing I noticed was that this tutorial is based on:

pragma solidity ^0.4.24;

However, the current version of Solidity is:

pragma solidity ^0.8.14;

macos$ solc --version
solc, the solidity compiler commandline interface
Version: 0.8.14+commit.80d49f37.Darwin.appleclang

Solidity version 0.4.24 was released in 2018 and has been long depreciated:

I don't have enough experience in Solidity to migrate code from a long depreciated version to a currently supported version.

macos$ solc token.sol
Error: Source file requires different compiler version (current compiler is 0.8.14+commit.80d49f37.Darwin.appleclang) - note that nightly builds are considered to be strictly less than the released version
 --> token.sol:1:1:
  |
1 | pragma solidity ^0.4.24;
  | ^^^^^^^^^^^^^^^^^^^^^^^^

Of course, changing the version in the file does not work , and the journey down the rabbit hole starts all over again, to a never ending barrage of Solidity compiler errors:

macos$ solc token.sol
Error: Expected '{' but got 'constant'
  --> token.sol:32:35:
   |
32 |     function totalSupply() public constant returns (uint);
   |

I worked on this for over an hour yesterday, and gave up frustrated. Fix one depreciated line, then another, then another. Customers should not be doing this with tutorial examples from their service providers. This would be hard in any programming language, going from version 0.4 to version 0.8, but Solidity is really annoying to code. Solidity is perhaps the most annoying programming language I have ever seen in the past 20 years!

My action was to contact the QuickNode tutorial author and ask to update their tutorial to use a recent, support ed version of Solidity. Let's see if they help us out. I'm not going to continue on with this obsolete 2018 code to learn Solidity in 2022, that's for sure!

More later....

Neo · June 10, 2022, 2:32am

A few days into this, and I'm beginning to think that Solidity is the worst part of Ethereum. There seems nothing "smart" about the design of the Solidity programming language. It's hard to imagine how Ethereum can withstand the test of time, based on such an ad-hoc, poorly designed "smart contract" programming language.

There is nothing "smart" about Solidity, as far as I have seen so far.

Update

Currently evaluating Alchemy and Chainstack blockchain providers on Ropsten, Rinkeby and Goerli Ethereum networks.

Today I quickly wrote a Ruby modules which generates key-pairs with addresses and put them into a DB using Rails. Then got some test ETH for each of these networks and and wrote come code to scan the DB and update the test ETH balances for all addresses based on the network.

I realized I have created my own wallet today using Rails, since wallets are nothing more than keychains, and that is what I have written today, a basic key-management app.

Starting to get the hang of it; but I'm still having small issues with deploying Ethereum contracts, but I am almost there

Neo · June 15, 2022, 4:02am

Continued here: