Frameworks can be used to ease Ethereum smart contracts development. By doing everything yourself you get a better understanding of how everything fits together, but it’s a lot of tedious, repetitive work. The frameworks listed below can automate certain tasks and make development a breeze.
Github link; https://github.com/trufflesuite/truffle
Website link; https://truffleframework.com
Documentation link; https://truffleframework.com/docs
Truffle Boxes link; http://truffleframework.com/boxes/
npm package repository link; https://www.npmjs.com/package/truffle
The truffle framework is made of several NodeJS packages. Before we install truffle, we need to have an up-to-date and working installation of NodeJS and the Node Package Manager (npm).
The recommended way to install NodeJS and npm, is to use the Node Version Manager (NVM), nvm. Once we install nvm, it will handle all the dependencies and updates for us. We’ll follow the instructions found at: http://nvm.sh
Once nvm is installed on your operating system, installing NodeJS is simple. We use the --lts flag to tell nvm that we want the most recent "Long Term Support (LTS)" version of NodeJS
$ nvm install --lts
Confirm you have node and npm installed:
$ node -v v8.9.4 $ npm -v 5.6.0
Create a hidden file .nvmrc that contains the Node.js version supported by your DApp so developers just need to run nvm install in the root of the project directory and it will automatically install and switch to using that version.
$ node -v > .nvmrc $ nvm install
Looking good. Now to install truffle:
$ npm -g install truffle + [email protected] installed 1 package in 37.508s
If we want to use or create a DApp that builds upon a pre-built boilerplate, then at the Truffle Boxes link we can choose an existing Truffle project, and then run the following to download and extract it:
$ truffle unbox <BOX_NAME>
For each project where we will use truffle, we create a project directory and initialize truffle within that directory. Truffle will create the necessary directory structure inside our project directory. Customarily, we give the project directory a name that describes our project. For this example, we will use truffle to deploy our faucet contract from [simple_contract_example], and therefore we will name the project folder Faucet.
$ mkdir Faucet $ cd Faucet Faucet $
Once inside the Faucet directory, we initialize truffle:
Faucet $ truffle init
Truffle creates a directory structure and some default files:
Faucet ├── contracts │ └── Migrations.sol ├── migrations │ └── 1_initial_migration.js ├── test ├── truffle-config.js └── truffle.js
We will also use a number of JavaScript (nodeJS) support packages, in addition to truffle itself. We can install these with npm. We initialize the npm directory structure and accept the defaults suggested by npm:
$ npm init
package name: (faucet)
version: (1.0.0)
description:
entry point: (truffle-config.js)
test command:
git repository:
keywords:
author:
license: (ISC)
About to write to Faucet/package.json:
{
"name": "faucet",
"version": "1.0.0",
"description": "",
"main": "truffle-config.js",
"directories": {
"test": "test"
},
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC"
}
Is this ok? (yes)
Now, we can install the dependencies that we will use to make working with truffle easier:
$ npm install dotenv truffle-wallet-provider ethereumjs-wallet
You now have a node_modules directory with several thousand files, inside your Faucet directory.
Prior to deploying the DApp to a cloud production or continuous integration environment it is important to specify the "engines" field so that your Dapp is built with the correct Node.js version and it’s associated dependencies are installed.
Package.json "engines" field configuration link; https://docs.npmjs.com/files/package.json#engines
Truffle creates some empty configuration files, truffle.js and truffle-config.js. On Windows systems the truffle.js name may cause a conflict when you try to run the command truffle and Windows attempts to run truffle.js instead. To avoid this, we will delete truffle.js and use truffle-config.js, in support of Windows users who, honestly, suffer enough already.
$ rm truffle.js
Now we edit truffle-config.js and replace the contents with:
module.exports = {
networks: {
localnode: { // Whatever network our local node connects to
network_id: "*", // Match any network id
host: "localhost",
port: 8545,
}
}
};The configuration above is a good starting point. It sets up one default Ethereum network (named localnode), which assumes you are running an Ethereum client (such as parity), either as a full node, or as a light client. This configuration will instruct truffle to communicate with the local node over RPC, on port 8545. Truffle will use whatever Ethereum network the local node is connected to, such as the Ethereum main network, or a test network like Ropsten. The local node will also be providing the wallet functionality.
In following sections, we will configure additional networks for truffle to use, such as the ganache test-RPC blockchain and Infura, a hosted network provider. As we add more networks, the configuration file will get more complex, but it will also give us more options for our testing and development workflow.
We now have a basic working directory for our Faucet project, and we have truffle and its dependencies configured. Contracts go in the contracts subdirectory of our project. The directory already contains a "helper" contract, Migrations.sol which manages contract upgrades for us. We’ll examine the use of Migrations.sol in a later section.
Let’s copy the Faucet.sol contract (from [solidity_faucet_example]) into the contracts subdirectory, so that the project directory looks like this:
Faucet ├── contracts │ ├── Faucet.sol │ └── Migrations.sol ...
We can now ask truffle to compile the contract for us:
$ truffle compile Compiling ./contracts/Faucet.sol... Compiling ./contracts/Migrations.sol... Writing artifacts to ./build/contracts
Truffle offers a deployment system called a migration. If you have worked in other frameworks, you may have seen something similar: Ruby on Rails, Python Django and many other languages and frameworks have a migrate command.
In all those frameworks, the purpose of a migration is to handle changes in the data schema between different versions of the software. The purpose of migrations in Ethereum is slightly different. Because Ethereum contracts are immutable and cost gas to deploy, truffle offers a migration mechanism to keep track of which contracts (and which versions) have already been deployed. In a complex project with dozens of contracts and complex dependencies, you would not want to have to pay to redeploy contracts that haven’t changed. You would also not want to manually track which versions of which contracts have been deployed already. The truffle migration mechanism does all that by deploying the smart contract Migrations.sol, which then keeps track of all other contract deployments.
We have only one contract, Faucet.sol, which means that the migration system is overkill, to say the least. Unfortunately, we have to use it. But, by learning how to use it for one contract, we can start practicing some good habits for our development workflow. The effort will pay off as things get more complicated.
Truffle’s migrations directory is where the migration scripts are found. Right now, there’s only one script 1_initial_migration.js, which deploys the Migrations.sol contract itself:
[[1_initial_migration]] .1_initial_migration.js - the migration script for Migrations.sol
include::code/Faucet/migrations/1_initial_migration.jsWe need a second migration script, to deploy Faucet.sol. Let’s call it 2_deploy_contracts.js. It is very simple, just like 1_initial_migration.js, with only a few small changes. In fact, you can copy the contents of 1_initial_migration.js and simply replace all instances of Migrations with Faucet:
[[2_deploy_contracts]] .2_deploy_contracts.js - the migration script for Faucet.sol
include::code/Faucet/migrations/2_deploy_contracts.jsThe script initializes a variable Faucet, identifying the Faucet.sol Solidity source code as the artifact that defines Faucet. Then, it calls the deploy function to deploy this contract.
We’re all set. Let’s use truffle migrate to deploy the contract. We have to specify on which network to deploy the contract, using the --network argument. We only have one network specified in the configuration file, which we named localnode. Make sure your local Ethereum client is running and then type:
Faucet $ truffle migrate --network localnode
Because we are using a local node to connect to the Ethereum network and manage our wallet, we have to authorize the transaction that truffle creates. I’m running parity connected to the Ropsten test blockchain, so during the truffle migration I will see a pop-up on parity’s web console:
You will see four transactions, total. One to deploy Migrations, one to update the deployments counter to 1, one to deploy Faucet and one to update the deployments counter to 2.
Truffle will show the migrations completing, show each of the transactions and show the contract addresses:
$ truffle migrate --network localnode Using network 'localnode'. Running migration: 1_initial_migration.js Deploying Migrations... ... 0xfa090db179d023d2abae543b4a21a1479e70ca7d35a469a5d1a98bfc6bd80fe8 Migrations: 0x8861c27715550bed8362c0345add158489df6db0 Saving successful migration to network... ... 0x985c4a32716826ddbe4eae284104bef8bc69e959899f62246a1b27c9dfcd6c03 Saving artifacts... Running migration: 2_deploy_contracts.js Deploying Faucet... ... 0xecdbeef77f0558edc689440e34b7bba0a3ba7a45e4b680b071b47c30a930e9d6 Faucet: 0xd01cd8e7bd29e4bff8c1693f59eee46137a9f300 Saving successful migration to network... ... 0x11f376bd7307edddfd40dc4a14c3f7cb84b6c921ac2465602060b67d08f9fd8a Saving artifacts...
Truffle offers a JavaScript console that we can use to interact with the Ethereum network (via the local node), interact with deployed contracts, and interact with the wallet provider. In our current configuration (localnode), the node and wallet provider is our local parity client.
Let’s start the truffle console and try some commands:
$ truffle console --network localnode truffle(localnode)>
Truffle presents a prompt, showing the selected network configuration (localnode). It’s important to remember and be aware of which network we are using. You wouldn’t want to accidentally deploy a test contract or make a transaction on the Ethereum main network. That could be an expensive mistake!
The truffle console offers an auto-complete function that makes it easy for us to explore the environment. If we press Tab after a partially-completed command, truffle will complete the command for us. Pressing Tab twice will show all possible completions if more than one command matches our input. In fact, if we press Tab twice on an empty prompt, truffle lists all commands:
truffle(localnode)> Array Boolean Date Error EvalError Function Infinity JSON Math NaN Number Object RangeError ReferenceError RegExp String SyntaxError TypeError URIError decodeURI decodeURIComponent encodeURI encodeURIComponent eval isFinite isNaN parseFloat parseInt undefined ArrayBuffer Buffer DataView Faucet Float32Array Float64Array GLOBAL Int16Array Int32Array Int8Array Intl Map Migrations Promise Proxy Reflect Set StateManager Symbol Uint16Array Uint32Array Uint8Array Uint8ClampedArray WeakMap WeakSet WebAssembly XMLHttpRequest _ assert async_hooks buffer child_process clearImmediate clearInterval clearTimeout cluster console crypto dgram dns domain escape events fs global http http2 https module net os path perf_hooks process punycode querystring readline repl require root setImmediate setInterval setTimeout stream string_decoder tls tty unescape url util v8 vm web3 zlib __defineGetter__ __defineSetter__ __lookupGetter__ __lookupSetter__ __proto__ constructor hasOwnProperty isPrototypeOf propertyIsEnumerable toLocaleString toString valueOf
The vast majority of the wallet and node related functions are provided by the web3 object, which is an instance of the web3.js library. The web3 object abstracts the RPC interface into our parity node. You will also notice two objects with familiar names: Migrations and Faucet. Those represent the contracts we just deployed. We will use the truffle console to interact with a contract. First, let’s check our wallet via the web3 object:
truffle(localnode)> web3.eth.accounts [ '0x9e713963a92c02317a681b9bb3065a8249de124f', '0xdb5dc1a13e3a55cf3b4587cd8d1e5fdeb6738145' ]
Our parity client has two wallets, with some test ether on Ropsten. The web3.eth.accounts attribute contains a list of all the accounts. We can check the balance of the first account, using the getBalance function:
truffle(localnode)> web3.eth.getBalance(web3.eth.accounts[0]).toNumber() 191198572800000000 truffle(localnode)>
The web3.js is a large JavaScript library that offers a comprehensive interface to the Ethereum system, via a provider such as a local client. We will examine web3.js in more detail in [web3js]. Now let’s try to interact with our contracts:
truffle(localnode)> Faucet.address '0xd01cd8e7bd29e4bff8c1693f59eee46137a9f300' truffle(localnode)> web3.eth.getBalance(Faucet.address).toNumber() 0 truffle(localnode)>
Next, we’ll use sendTransaction to send some test ether to fund the Faucet. Note the use of web3.toWei to convert ether units for us. Typing eighteen zeros without making a mistake is both difficult and dangerous, so it’s always better to use a unit converter for values. Here’s how we send the transaction:
truffle(localnode)> web3.eth.sendTransaction({from:web3.eth.accounts[0], to:Faucet.address, value:web3.toWei(0.5, 'ether')});
'0xf134c75b985dc0e0c27c2f0412251e0860eb530a5055e660f21e7483ab336808'
Switch to the web console on parity, where you will see a pop-up asking you to confirm this transaction. Wait a minute and once the transaction is mined, you will be able to see the balance of our Faucet contract:
truffle(localnode)> web3.eth.getBalance(Faucet.address).toNumber() 500000000000000000
Let’s call the withdraw function now, to withdraw some test ether from the Faucet:
truffle(localnode)> Faucet.deployed().then(instance => {instance.withdraw(web3.toWei(0.1, 'ether'))}).then(console.log)
Again, you will need to approve the transaction in the parity web console. The balance of the Faucet has decreased, and our test wallet has received 0.1 ether:
truffle(localnode)> web3.eth.getBalance(Faucet.address).toNumber() 400000000000000000
truffle(localnode)> Faucet.deployed().then(instance => {instance.withdraw(web3.toWei(1, 'ether'))})
StatusError: Transaction: 0xe147ae9e3610334ada8d863c9028c12bd0501be2d0cfd05865c18612b92d3f9c exited with an error (status 0).
Read the docs link; https://embark.readthedocs.io/en/2.6.4/
npm package repository link; https://www.npmjs.com/package/embark
$ npm -g install embark
OpenZeppelin is an open framework of reusable and secure smart contracts in the Solidity language.
It is community-driven, led by the Zeppelin team, with over a hundred external contributors. The main focus of the framework is security, achieved by applying industry standard contract security patterns and best practices, taking advantage of all the experience the Zeppelin devs have gained from auditing a huge amount of contracts, and through the constant testing and auditing from the community that uses the framework as a base for their real world applications.
The OpenZeppelin framework is the most widely used solution for Ethereum smart contracts. This is due to the community discussing every proposed solution and learning from the implementation and integration of these solutions, which turns into a growing feedback loop that improves the existing contracts and finds new possibilities to combine them in a clear and secure architecture. It has resulted in the constant addition of new reusable contracts to solve increasingly complex challenges or explore exciting new possibilities on top of the Ethereum blockchain. As mentioned before, the framework currently has an ample library of contracts ranging from implementations of ERC20 and ERC721 tokens, to many flavors of crowdsale models, to simple behaviors commonly found in contracts such as Ownable, Pausable or LimitBalance. The contracts in this repository in some cases even function as de facto standard implementations.
The framework has an MIT license, and all the contracts have been designed with a modular approach to guarantee ease of reuse and extension. These are clean and basic building blocks, ready to be used on your next Ethereum project. Let’s set up the framework and build a simple crowdsale using the OpenZeppelin contracts, as an example of how easy it is to use. This example also stresses the importance of reusing secure components instead of writing them by yourself, and gives a small sample of the ideas that the Ethereum platform and its community are making possible.
First, we will need to install the openzepelin-solidity library from npm into our workspace. The latest release as of the time of this writing is v1.9.0, so we will use that one.
mkdir sample-crowdsale cd sample-crowdsale npm install [email protected] mkdir contracts
For the crowdsale, we will need to define a token that we will give to the investors in exchange for their ether. At the time of writing, OpenZeppelin includes multiple basic token contracts that follow the ERC20, ERC721 and ERC827 standards, with different characteristics for emission, limits, vesting, lifecycle, etc.
Let’s make an ERC20 token that’s mintable, meaning that the initial supply starts at 0 and new tokens can be created by the token owner (in our case, the crowdsale contract) and assigned to the investors. In order to do this, create a contracts/SampleToken.sol file with the following contents:
include::code/OpenZeppelin/contracts/SampleToken.sol
OpenZeppelin already provides a MintableToken contract that we can use as a base for our token, so we only define the details that are specific to our case. You can trust that the community has put great effort to ensure the correctness of the contract, but it’s always better to verify this by ourselves. Take a look at the source code for MintableToken, StandardToken, and Ownable to understand the implementation details of your new token and the capabilities it supports. Also, take a look at the automated tests it has, to make sure that all the possible scenarios have been covered and that the code is safe.
Next, let’s make the crowdsale contract. Just like with tokens, OpenZeppelin already provides a wide variety of crowdsale flavors. Currently, you will find contracts for scenarios involving distribution, emission, price, and validation. So, let’s say that you want to set a goal for your crowdsale and if it’s not met by the time the sale finishes, you want to refund all your investors. For that, you can use the RefundableCrowdsale contract. Maybe you want to define a crowdsale with an increasing price to incentivize early buyers; there is the IncreasingPriceCrowdsale contract just for that. Or maybe end the crowdsale when a specified amount of ether has been received by the contract CappedCrowdsale, or set a finishing time with the TimedCrowdsale contract, or a whitelist of buyers with the WhitelistedCrowdsale contract.
As we said before, the OpenZeppelin contracts are basic building blocks. These crowdsale contracts have been designed to be combined, just read the source code of the base Crowdsale contract for directions on how to extend it. For the crowdsale of our token, we need to mint tokens when the ether is received by the crowdsale contract, so let’s use MintedCrowdsale as a base. And to make it more interesting, let’s make it also a PostDeliveryCrowdsale so the tokens can only be withdrawn after the crowdsale ends. Write the following into contracts/SampleCrowdsale.sol:
include::code/OpenZeppelin/contracts/SampleCrowdsale.sol
Again, we almost didn’t have to write any code, but just to reuse the already battle-tested code that the OpenZeppelin community made available for us. However, it is important to note that this case is different than the one of our SampleToken contract. If you go to the Crowdsale automated tests you will see that they are tested in isolation. When you integrate different units of code into a bigger component, it’s not enough to test all the units separately because the interactions between them might cause behaviors that you didn’t expect. In particular, you will see that here we introduced multiple inheritance, which can surprise the developer if they don’t understand the implementation details of the Solidity compiler. Our SampleCrowdsale is simple, and it will work just as we expect because the framework was designed to make cases like these straightforward; but do not relax your security because of the simplicity that this framework introduces. Every time you integrate parts of the OpenZeppelin framework to build a more complex solution, you must fully test every aspect of your solution to ensure that all the interactions of the units work as you intend.
Finally, after we are happy with our solution and we have tested it thoroughly, we need to deploy it. OpenZeppelin integrates well with Truffle, so we can just write a migrations file as explained in the Truffle section above. Write the following in migrations/2_deploy_contracts.js:
include::code/OpenZeppelin/migrations/2_deploy_contracts.js
This was just a quick overview of a few of the contracts that are part of the OpenZeppelin framework. There are many more, and the community is always proposing ideas for new ones, implementing new strategies to make them safer, simpler and clearer, and trying to find holes early to prevent vulnerabilities on the mainnet contracts. You are welcome to join the community to learn and contribute.
Website link; https://openzeppelin.org/
zeppelin_os is an open-source, distributed platform of tools and services on top of the EVM to develop and manage smart contract applications securely.
Unlike OpenZeppelin’s code, which needs to be re-deployed with each application every time, zeppelin_os’s code lives on-chain. Applications that need a given functionality, say, an ERC20 token, not only do not have to re-design and re-audit its implementation (something that OpenZeppelin solved) but do not even need to deploy it. With zeppelin_os, an application interacts with the token’s on-chain implementation directly, in much the same way as a desktop application interacts with the components of its underlying OS.
Applications that make use of OpenZeppelin avoid having to "reinvent the wheel" by reusing the library’s curated and peer reviewed contracts. However, every single time an application uses an ERC20 token implementation, the same ERC20 bytecode is deployed into the blockchain, over and over again. Such bytecode exists duplicated in the network countless times. Now, applications that make use of zeppelin_os avoid this unnecessary duplication. Instead of deploying their own ERC20 implementation, they link to a contract that defines the latest ERC20 implementation accepted by the community. This single, central implementation is deployed in the blockchain only once, much like Solidity’s libraries, but are considerably more sophisticated.
Unlike Solidity’s libraries, the implementations offered by zeppelin_os can be treated like regular contracts, i.e. they have storage. Also, they are upgradeable. If a vulnerability is ever found in one of the OS’s official implementations, it can simply be swapped with an upgraded one. In the case of the ERC20 token, an upgrade to its implementation would instantly ripple to all the applications that use it. The OS not only provides upgradeability for all of its implementations, but also for the user’s own contracts, and even for it’s own codebase! Developers decide when and how an application should implement an upgrade, and even which "flavor" of an implementation to adhere to.
At the core of zeppelin_os sits a very clever contract known as a "proxy". A proxy is a contract that is capable of wrapping any other contract, exposing its interface without having to manually implement setters and getters for it, and can upgrade it without losing state. In Solidity terms, it can be seen as a normal contract whose business logic is contained within a library, which can be swapped by a new library at any time without losing its state. The way in which the proxy links to its implementation is completely automated and encapsulated for the developer. Practically any contract can be made upgradeable with little to no change in its code. More about zeppelin_os’s proxy mechanism can be found in Zeppelin’s blog: upgradeability-using-unstructured-storage, and an example of how to use it can be found here: https://github.com/zeppelinos/zos-lib/tree/master/examples/single.
The OS wraps its implementations in packages or "releases" that can be vouched for using ZepTokens. ZepTokens can hence be staked against a release, signaling it as the community’s accepted implementation set. Anyone can submit new releases that can be scrutinized by the community and eventually accepted as official. As a reward, developers of a release receive tokens each time it is vouched for. As a Dapp developer, vouching provides a measurable way to determine how much is staked for a given release, and hence how much it can be trusted.
Developing applications using zeppelin_os is similar to developing Javascript applications using NPM. An AppManager handles an application package for each version of the application. A package is simply a directory of contracts, each of which can have one or more upgradeable proxies. The AppManager does not only provide proxies for application-specific contracts, but does so also for zeppelin_os implementations in the form of a standard library. To see a full example of this, please visit: examples/complex. //// TODO: the example provided above is still a WIP - link to a tutorial once it’s finished
Although currently in development, zeppelin_os aims to provide a wide set of additional features, such as developer tools, a scheduler that automates background operations within contracts, development bounties, a marketplace that facilitates communication and exchange of value between applications and much more. All of this is described in zeppelin_os’s whitepaper.pdf.
Github link; https://github.com/zeppelinos Website link; https://zeppelinos.org Blog: https://blog.zeppelinos.org Github: https://github.com/zeppelinos
helpeth is a command line tool for key and transaction manipulation that makes a developer’s job a lot easier.
It is part of the ethereumjs collection of JavaScript based libraries and tools.
Usage: helpeth [command] Commands: signMessage <message> Sign a message verifySig <hash> <sig> Verify signature verifySigParams <hash> <r> <s> <v> Verify signature parameters createTx <nonce> <to> <value> <data> Sign a transaction <gasLimit> <gasPrice> assembleTx <nonce> <to> <value> <data> Assemble a transaction from its <gasLimit> <gasPrice> <v> <r> <s> components parseTx <tx> Parse raw transaction keyGenerate [format] [icapdirect] Generate new key keyConvert Convert a key to V3 keystore format keyDetails Print key details bip32Details <path> Print key details for a given path addressDetails <address> Print details about an address unitConvert <value> <from> <to> Convert between Ethereum units Options: -p, --private Private key as a hex string [string] --password Password for the private key [string] --password-prompt Prompt for the private key password [boolean] -k, --keyfile Encoded key file [string] --show-private Show private key details [boolean] --mnemonic Mnemonic for HD key derivation [string] --version Show version number [boolean] --help Show help [boolean]
Installing:
$ curl https://nixos.org/nix/install | sh
$ nix-channel --add https://nix.dapphub.com/pkgs/dapphub
$ nix-channel --update
$ nix-env -iA dapphub.{dapp,seth,hevm,evmdis}
SputnikVM is a standalone pluggable virtual machine for different Ethereum-based blockchains. It’s written in Rust, can be used as a binary, cargo crate, shared library, or integrated through FFI, Protobuf and JSON interface. It has a separate binary sputnikvm-dev intended for testing purposed, which emulates most of JSON RPC API and block mining.
Github link; https://github.com/etcdevteam/sputnikvm
web3.js is the Ethereum compatible JS API for communicating with clients via JSON RPC, developed by the Ethereum foundation.
Github link; https://github.com/ethereum/web3.js
npm package repository link; https://www.npmjs.com/package/web3
Documentation link for web3.js API 0.2x.x; https://github.com/ethereum/wiki/wiki/JavaScript-API
Documentation link for web3.js API 1.0.0-beta.xx; https://web3js.readthedocs.io/en/1.0/web3.html
web3.py is a Python library for interacting with the Ethereum blockchain. It now lives in the Ethereum Foundation’s GitHub too.
Github link; https://github.com/ethereum/web3.py
PyPi link; https://pypi.python.org/pypi/web3/4.0.0b9
Documentation link; https://web3py.readthedocs.io/
a collection of libraries and utilities for Ethereum.
Github link; https://github.com/ethereumjs
Website link; https://ethereumjs.github.io/
web3j is the Java and Android library for integrating with Ethereum clients and working with smart contracts.
Github link; https://github.com/web3j/web3j
Website link; https://web3j.io
Documentation link; https://docs.web3j.io
Etherjar is another Java library for integrating with Ethereum and working with smart contracts. It’s designed for server side projects based on Java 8+, provides low level access and high level wrapper around RPC, Ethereum data structures and Smart Contract access
Github link; https://github.com/infinitape/etherjar
Nethereum is the .Net integration library for Ethereum.
Github link; https://github.com/Nethereum/Nethereum
Website link; http://nethereum.com/
Documentation link; https://nethereum.readthedocs.io/en/latest/
The ethers.js library is a compact, complete, full-featured, extensively tested Ethereum library fully licensed under the MIT license, and has received a DevEx grant from the Ethereum Foundation to extend and maintain.
GitHub link: https://github.com/ethers-io/ethers.js
Documentation: https://docs.ethers.io
Emerald Platform provides libraries and UI components to build Dapps on top of Ethereum. Emerald JS and Emerald JS UI provides set of modules and React components to build Javascript applications and websites, Emerald SVG Icons is a set of blockchain related icons. In addition to Javascript libraries it has Rust library to operate private keys and transaction signatures. All Emerald libraries and components are licensed under Apache 2 license.
Documentation link; https://docs.etcdevteam.com