Technologies Archives

In this article we will look at Web3 RPC Nodes, Initially we shall explain remote procedure calls ( RPC ) in both web2 and web3. After this you will get a chance to interact with an RPC and dive into the internet of blockchains ( Cosmos ), The purpose of this is to help you understand the role of RPC Nodes in Web3 and highlight the caveat of centralised RPC infrastructure in decentralised network. Finally we will look at a hot new solution to this problem!

What is RPC?

Remote Procedure Calls are used in Client – Server systems, the behavioral flow is the client will send a request to the server and the server will respond with a result. During this exchange the client may specify a particular function or procedure and pass relevant parameters with it.

Web 2 RPC’s

Let’s look at an example with two systems, Wordpress (CMS) and Moodle (LMS). We want to automatically enroll a customer in a Moodle course ( and create their account if it does not already exist ) after they purchase a course from Wordpress. In Moodle we configure the default provided RPC options or write some custom functionality if needed. In wordpress we write or find a plugin for Moodle integration and then configure the Moodle Server RPC particulars. The systems can securely communicate via the security token generated in Moodle, and for specified functions such as userExists, createUsers, authUser. getUser courseList, enrollUser.

RPC’s allow us to integrate with systems and easily read/change data within it for an intended purpose. It affords simpler integration with many systems through a system defined interface.

But what about Web3 RPC Nodes, you ask? Let’s get into that, if you are new to the space the term node is used instead of server.

Web 3 / Blockchain RPC Nodes

RPC Nodes are our gateway to read from and interact with the blockchain through their exposed API interface. With the blockchain we cannot communicate directly with it as we can a database. These RPC Nodes are essential for our dApps and anything else want interact with the blockchain need to use these to interface with it. From the clients perspective they must submit our transaction with their wallet and this has a configured RPC Node, their transaction will be submitted through that access point. This action could be to transfer some tokens, interact with some smart contracts, trade, yield farm, stake or some other feature offered by a dApp.

What if the RPC is offline?

If our configured RPC node is offline then our wallet should return some error and inform us, at this point a lot of people will be left scratching their head and unsure what to do. Perhaps they would just try again later. Searching for an RPC for your chosen blockchain may net you an alternative. Do you need to trust it? Are all of them good actors?

If we have a dApp that we have built and it uses the RPC Nodes API for regular operations, you will be out of action unless you have incorporated a list of trusted backup RPC Nodes and the functionality to iterate through the list in the event of failure. The uptime and reliability of RPC Nodes are essential to the services provided and for the user experience.

How can we trust RPC?

This is one of the achilles heels of web3 at the moment, let’s say someone runs a RPC Node with the intention of theft. They download the source code and make some modifications to it. And convince users to configure this inside their wallets. Perhaps instead of processing a transaction they throw an error message and suggest a user go to their own phishing site where they have the user sign a transaction and drain their wallet.

A similar event happened this year, a RPC Node became compromised and the attackers did this very ploy to phish users to their own website to deprive them of their assets.

Cosmos RPC Nodes & Tendermint

Cosmos is an Internet of blockchains as such there are a multitude of blockchain that exist and are interoperable. Tendermint allows for the integration of any blockchain into this ecosystem, it frees up application developers to be able to focus on their creations and not have to concern themselves with the gargantuan task of building a network or deciding on and implementing consensus methods. This modularity ( separation of application, network and consensus layer) is already the reason this network is growing at a breakneck speed. As more and more chains decide to take advantage of the Cosmos architecture and interoperability there becomes a large target placed upon these RPC Nodes for attacks, if this infrastructure exists on centralised services then there becomes a honeypot and compromises will have wide scale impacts.

Explore Cosmos via Tendermint RPC

Lets get our hands a little dirty!

If you are new to blockchain there is no better way to get familiar with it then getting your hands dirty. Take a look at the latest COSMOS block

View Latest Cosmos Block

If you prefer to look at this inside postman, below is a collection to get you started.

Tendermint RPC – Swagger Download

Now that you are interacting with data from the blockchain save the link below to explore more!

Tendermint RPC – Full API Description

Critical Infrastructure – Should it be decentralized?

When we have billions of dollars and services that hundreds of millions use the underlying infrastructure, its reliability, security, transparency and motivations need to be considered. In the last two years their explosive growth has resulted in a lot of centralization of services which offer fast and quick results for developers and users ( a short term win! ), In the medium term this introduces risks and dilutes some of the founding principle cores. A core tenet of Web3 is decentralization, if that becomes diluted to the point where it barely exists at all levels then what is Web3? With that in mind can we trust centralized services to be the gatekeepers of a decentralized system?

If you looked at the current cosmos block using the links or postman file above how do you know the data that is returned to you is accurate? What is stopping a centralised service from misrepresenting the chains state.

Will they restrict access arbitrarily upon government request?

Will they censor or curate information in ways that are not representative of the blockchains actual state?

Will they serve as a focal point for attacks to compromise networks and harm users?

If they go out of business will all the services built relying on them also disappear?

Many of us have been happy to forget about the value of decentralization especially when we are not encountering any of the downsides that come with centralisation. This is a core part of Web3 though not an immediately obvious one. When this matters it can be the difference of you having access to your assets or not. Being able to use the services built on blockchains or not.

It seems to me that now is the time to re-evaluate our relationship with how we interact with blockchains via RPC Nodes. As we move towards an interoperable ecosystem within cosmos. Centralized services create a single point of failure, that impact ripples to all chains which become part of the Cosmos ecosystem, such an expansive network which in time could include all chains. After all it is the internet of blockchains.

The solution – LAVA

In 2022 a visionary team was established to revolutionize the way we interact with blockchains. To ensure centralization and the points of failure they introduce do not go without challenge and are stopped before their corrosive impacts on decentralization become widespread, ingrained and exploited regularly.

It is my desire to be at the forefront of this mission, to help guide developers coming into the space in a way that promotes and spreads the core values of Web3, removes barriers of entry, resolve development issues and foster a community that will lead the whole industry into the next era. An era in which those who thrive will be decentralised and censorship resistant. It’s time to take the discussion beyond a network of value transfers, and bring it full circle to the values which established this entire space. The future is hot, The future is liquid, The future is LAVA!

After working with drupal for years I am amazed by the number of custom modules out there and what they have unleased for business’s that have used them and continue to innovate more. The ones I refer to here are the publicly accessable ones, I believe there are just as many which are private and are highly specialised to the business that have them developed. This is the use case I am wanting to target here. These Custom Modules are ones you can create for a clients specific needs.

In Drupal 9 custom modules off there flexibility to create entirely new features and/or adjust existing ones to enhance a business’s growth or open up new lines of what they offer. It allows virtually unlimited creativity and possibility for owner of a Drupal system. For Developers if offers then a way to provide highly novel solutions for those busssiness.

The aim of this article is to help you build your first basic custom module in Drupal 9. Note these will also work for Drupal 8 ( D8 is end of life and migration plans ideally would be underway, if not, reach out to me and we may be able to work together on it)

Drupal 9 Module development

Lets getCoding! and create this module in just a few phases.

Phase 1: The Name

A great place to start is to decide on the name of your module and then we can create it under the folder path “/modules/custom”. The one ill choose for this article is “simple_module“. You will notice my root folder is called drupal_tutorals yours may be configured as web, root or something else

Rules for naming:

start it with lower case letters, (simple_module, not, Simple_Module)
no spaces in the name. ( simple_module, not, simple module)

done!, lets get onto the next phase

Phase 2: Create info.yml file ( for Drupal to recognise it)

Next we need to create a .yml file. If you are unfamiliar with what a .yml ( or .yaml) file is it is a format that is great for storing configuration it is a superset of JSON and not a markup language, if you want to learn more about JSON read this article.

So in short the .yml is a configuration file for our module which allows drupal to know about it. We create a file in our new folder (simple_module) and call it simple_module.info.yml, put the following code into it

name: Simple Module
type: module
description: 'Demo a creating a simple Drupal 9 Module.'
package: Custom
version: 0.5
core_version_requirement: ^8 || ^9

Lets look at what each of these config items is

name: This is the name that will get displayed in the modules list in our Drupal admin section

type: this will be either module or theme, in our case module

description: a longer description of the module that will appear in the Drupal admin section under the name

package: specify this as being custom module

version: this is our module version, I have put 0.5 as it is in dev, for a full ready release it should go out as 1.0 )

core_version_requirement: let it know which versions of Drupal this will work with ( 8/9)

That is our config done! Nice we are almost there now we just need to add our Router file and our controller!

Phase 3: Create Module Routing, routing.yml

I really like the routing system in Drupal 8/9, it replaces the routing parts of the hooks_menu() that was in Drupal 7. The routing system is mostly based on Symfony’s, so where I say mostly it can do everything that Symfony’s can and more, both Drupal 8/9 and Symfony use the same syntax to define routes.

In short: Routing is where our pages will be accessed via URL’s

Create a file simple_module.routing.yml in our simple_module folder and add the following

simple_module.demopage:
  path: '/simple/demopage'
  defaults:
    _controller: '\Drupal\simple_module\Controller
\SimpleController::demopage'
    _title: 'Simple Demo page for Drupal 9'
  requirements: 
    _permission: 'access content'

So lets unpack what we have here in the simple_module.routing.yml file

Line #1: is the route name

Line #2: The URL page this route will be regestered to eg https://demo.com/simple/demopage

Line #4: Is a reference to the _controller and a demopage class() that is within this controller ( we will be making this file next)

Line #5: The _title ( default title ) of the page for the controller we specify in Line #4

Line #7: List of _permission that are needed to access the module, here we just want a public page so access content is the only one needed, if we were creating an admin page or something within a user profile then we would add some more restrictive permissions

So far we have now got the shell of our module ( phase 1 & 2 ) the routing information of where to access the page we are making ( phasev3) . Now for our final phase.

As mentioned on Line #4: The controller is what we need next so that we can build out the meat of our custom module and put in the actual behavours of what will be on the page this is what our controller will do

Phase 4: Create a Controller

In the folder we created in step 1 (/modules/custom/simple_module) we need to create some additional folders

(/modules/custom/simple_module/src/Controller) and also a file “SimpleController.php” and in it put the following

<?php
namespace Drupal\simple_module\Controller;
class SimpleController {
  public function demopage() {
    return array(
      '#markup' =----> 'Congratulations, you have made your a Custom Module in Drupal 9!</br>Time to Celebrate!</br>Don't forget to reward yourself!'
    );
  }
}

From here we are done with the code!

Your files should look something like this

Log into your Drupal installation and enable the simple module we just created. As always we need to check that what we have done works so navigate to /simple/demopage , you may need to clear the cache if it does not work.

admin / configuration / performance and then clear cache on that page.

Try the location /simple/demopage again.

Thats the end. Whilst the module itself does not do anything you now are able to create a custom module and then implement what it is your client or company needs.

You can access the code for this module at this GitHub repo