Skip to content

Full Stack Java Dev in the Crypto space – Ethereum

Java Dev Entering the Crypto Space - Ethereum

Most of my life I’ve been Java Dev and in recent times I’ve started Entering the Crypto Space – Ethereum to be exact. There are several articles, tutorials, places to get to know the stuff in theory.  After you’ve understood the basics (Ethereum for Java Developers), there is the Web3J library to start getting your hands dirty. Here is a web3j tutorial from a popular Java Guy that I’ve personally used. But, in today’s article you’ll read what I’m seeing from my broader programming & philosophical perspective in my own path of learning the technology.

Total mess in the Architecture

As a software developer, you should have clear picture when and where is the logic in the source code executed. If the programmer does not know it, he is just gambling with source code changes.

  • There are big backend systems that are modular and orchestrated in micro services. Many times they are hard to debug for the exactly the above reason.
  • The Front-End Development also evolved a lot. Many frameworks embraced complex architectures. What code is executed by which actor in the Software Pipeline/Workflow is blurring with the evolution of the abstractions.
    • On the client side – it is the browser or the mobile/desktop app,
    • On the back end – the application server, the database, or whatever system.
  • There are some libraries that purposefully try to hide all the backend/frontend complexity.

If you do not understand all the above, the blockchain stuff will be the tip of the iceberg for you, especially if you code in NodeJS.

This is because you could approach the Blockchain integrated apps and services from the Client Side (Example – the browser) or from the Back End Side with JavaScript, Java, or something else.

Total mess in the tech stacks

Bitcoin is originally written in C++ because it needs speed of execution. Several Wallets, Explorers, Clients and Nodes are written or based on that code. Ethereum also uses C++ in its the programming language – Solidity, plus other tools.

The Ethereum protocol has official implementation in Go Programming Language. Some of the tools for the testing/development are also Go Based.

The Tools in the Browsers and many of the Apps are coded in JavaScript. There is a backend implementation of the communication layer between the NodeJS backend and a Ethereum Node. Many of the tools in the testing and development phase are also written in JavaScript. There are Solidity Compilers (or/and wrappers) that use NodeJS.

There are also bunch of stuff made with typescript, python, c#, and who knows what tools, APIs, wrappers and SDKs that I don’t know about.

You probably get the Picture. There is total mix of programming languages, tools and software you will need to – program, test, connect, debug, and run in production – a client app that connects and uses the blockchain.

Solidity ~ Java

The Solidity programming language is somehow similar to Java. The Core building block in it is the Contract, instead of Object. It has inheritance, definition of visibility of code and variables, and many more well known concepts. But, When you think of contract, you must think of (RPC/Web) Service exposed by the Ethereum Protocol and not as some lower level building block.

EVM ~ JVM | Compilation | Deployment

Solidity code is compiled to Ethereum VM bytecode. To be executed, it needs to be deployed to the Blockchain first. To be executed by a Java Program, it needs a Generated Java Wrapper – from the Web3J Library. The other way to execute your Smart Contract is from the Raw RPC, where things are a little bit in the lower code level. You will call your Contract definitions with less abstractions and Object Oriented Thinking and Interfaces.

Ethereum Wallet ~ Program Caller/Executor

  1. You execute Blockchain Apps – when their code call gets attached to a block and verified by the network. This network could be
    1. Your Localhost ONLY
    2. Public Test Environment with temporary and mock data, chains, wallet coins etc.
    3. The Actual Public/Production Blockchain.
  2. To archive this, you pay to the network to append your call inside a block in the chain.
  3. To archive this, first – you need a Wallet with some amount of Ether that you must spend.
  4. Attaching a new item in a block is called a transaction.
  5. When the network approves the transaction, your code will finally be executed.

Java Server ~ Ethereum Node/Client

You cannot and you don’t interact with the whole Network in a obvious manner. Instead – you actually hit a remote procedure endpoint of an Ethereum Node. Here are the Options:

  • You could download and execute the Full Node and contribute to the Decentralization. You append your changes to your local version of the Blockchain. After the synchronization of the Full Ethereum Node with the (Torrent Like) Network (Verified by – currently – Proof Of Work)  and everything is OK, your code gets executed.
  • The second option is to run a Lite Node – called client – that only keeps the tip of the Full Node. This way you semi-delegate the synchronization work to some other participant.
  • The least decentralized option is to entirely depend on the Ethereum Node that belongs to someone else.

I haven’t started getting into the Ethereum scaling solutions – layers 1 and 2 – that try to increase the transactions in a block with less fees. They are a trade-off of – less decentralisation & control. I’m already sure that they will introduce more complexity and new code execution levels, APIs and tools to learn.

So, at this point, you probably get the picture how much work and layers of code it takes to actually be decentralized.

Leave a Reply

Your email address will not be published.