DEV Community: Josh Fischer

Building and deploying a smart contract with OpenZepplin and Solidity in less than 10 minutes

Josh Fischer — Fri, 08 Nov 2024 13:02:51 +0000

I've been developer for over 10 years now. I've been lucky enough to become an Apache committer and PPMC, speak at Google, write a book for Manning Publications, and a few other things. As the job market is not great and people are struggling to find good work, I'm starting to see business opportunities in blockchain, more specifically - I see some great opportunities to help others build their own businesses. I'd like to share some technical things I've learned in the last few weeks.

I’ve been working through understanding the pros and cons of distributed applications (DApps). There are many tools out there for you to choose from to get started in building them. In this article I’m giving you an opinionated approach to building, deploying and interacting with smart contracts locally. No web based tools, only command line.

Prerequisites:

I'm using Node 18.17, however, this should work with a later version of node.

Install node 18.17, if you don't have it already

$ nvm install 18.17

First, create your folder and `cd` into it

$ mkdir hello-world && cd hello-world

Initialize the project

$ npm init -y

Install Hardhat locally in our project

$ npm install --save-dev hardhat

Sidenote about npx

npx is used to run executables installed locally in your project. It’s recommended to install Hardhat locally in each project so that you can control the version on a project by project basis.

Setting up a Project

$  npx hardhat init
Need to install the following packages:
  hardhat@2.22.15
Ok to proceed? (y) 

You should see the option show up.  Select “ Create an empty hardhat.config.js”

You'll see this upon successful creation.

✔ What do you want to do? · Create an empty hardhat.config.js
✨ Config file created ✨

To verify everything executed as expected you should now see two field in your current directory.

See what's been created in your directory

$ ls -lta
package.json
hardhat.config.js

Build you first contract

When using Hardhat you can store Solidity source files (.sol) in a contracts directory. We will write our first simple smart contract, called Storage: it will let people store a value that can be later retrieved. It's a variation of another starter contract with Hardhat. I'm working through the process manually so we understand all of the moving pieces.

Create the contracts folder and open the file for editing

$ mkdir contracts &&  vim contracts/Storage.sol

Add the following to the `Storage.sol` file

// contracts/Storage.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract Storage {
    uint256 private _value;
    // Emitted when the stored value changes
    event ValueChanged(uint256 value);
    // Stores a new value in the contract
    function store(uint256 value) public {
        _value = value;
        emit ValueChanged(value);
    }
    // Reads the last stored value
    function retrieve() public view returns (uint256) {
        return _value;
    }
}

After writing the above to the file close vim with :wq or :x

Compiling Solidity

The Ethereum Virtual Machine (EVM) cannot execute Solidity code directly: we first need to compile it into EVM bytecode. Our Storage.sol contract uses Solidity 0.8 so we need to first configure Hardhat to use an appropriate solc version. We specify a Solidity 0.8 solc version in our hardhat.config.js.

/** @type import('hardhat/config').HardhatUserConfig */
module.exports = {
  solidity: "0.8.27",
};

Run the command

$  npx hardhat compile      
Compiled 1 Solidity file successfully (evm target: paris).

Deployment set up

We will create a script to deploy our Storage contract. We will save this file as scripts/deploy.js.

 $ mkdir scripts && vim scripts/deploy.js

// scripts/deploy.js
async function main () {
  // We get the contract to deploy
  const Storage = await ethers.getContractFactory('Storage');
  console.log('Deploying...');
  const storage = await Storage.deploy();
  await storage.waitForDeployment();
  console.log('Storage deployed to:', await storage.getAddress());
}

main()
  .then(() => process.exit(0))
  .catch(error => {
    console.error(error);
    process.exit(1);
  });

We use ethers in our script, so we need to install it and the @nomicfoundation/hardhat-ethers plugin.

$ npm install --save-dev @nomicfoundation/hardhat-ethers ethers
We need to add in our configuration that we are using the @nomicfoundation/hardhat-ethers plugin.

Our hard hat config should now look like this;

require("@nomicfoundation/hardhat-ethers");
/** @type import('hardhat/config').HardhatUserConfig */
module.exports = {
  solidity: "0.8.27",
};

Set up a local blockchain

We need an environment where we can deploy our contracts. The Ethereum blockchain (often called "mainnet", for "main network") requires spending real money to use it, in the form of Ether (its native currency). This makes it a poor choice when trying out new ideas or tools.

To solve this, a number of "testnets" (for "test networks") exist: However, you will still need to deal with private key management, blocktimes of 12 seconds or more, and actually getting this free Ether.

During development, it is a better idea to instead use a local blockchain. It runs on your machine, provides you with all the Ether that you need, and mines blocks instantly.

Create a local instance

$ npx hardhat node
Started HTTP and WebSocket JSON-RPC server at http://127.0.0.1:8545/
Accounts
========
WARNING: These accounts, and their private keys, are publicly known.
Any funds sent to them on Mainnet or any other live network WILL BE LOST.

Deploying the Smart Contract

Deploy your smart contract

$ npx hardhat run --network localhost scripts/deploy.js       
Deploying Storage...
Storage deployed to: 0x5FbDB2315678afecb367f032d93F642f64180aa3

Interacting from the Console

With our Storage contract deployed, we can start using it right away.
We will use the Hardhat console to interact with our deployed Storage contract on our localhost network.

We need to specify the address of our Storage contract we displayed in our deploy script.

It’s important that we explicitly set the network for Hardhat to connect our console session to. If we don’t, Hardhat will default to using a new ephemeral network, which our Storage contract wouldn’t be deployed to.

$ npx hardhat console --network localhost
Welcome to Node.js v20.17.0.
Type ".help" for more information.
> const Storage = await ethers.getContractFactory('Storage');
undefined
> const storage = Storage.attach('0x5FbDB2315678afecb367f032d93F642f64180aa3');
undefined

Sending transactions

The first function, store, receives an integer value and stores it in the contract storage. Because this function modifies the blockchain state, we need to send a transaction to the contract to execute it.
We will send a transaction to call the store function with a numeric value:

> await storage.store(76);
ContractTransactionResponse {
  provider: HardhatEthersProvider {
    _hardhatProvider: LazyInitializationProviderAdapter {
      _providerFactory: [AsyncFunction (anonymous)],
      _emitter: [EventEmitter],
      _initializingPromise: [Promise],
      provider: [BackwardsCompatibilityProviderAdapter]
    },
    _networkName: 'localhost',
    _blockListeners: [],
    _transactionHashListeners: Map(0) {},
    _eventListeners: []
  },
  blockNumber: 3,
  blockHash: '0xb643517cd642a31404381fc32fcb7ba3ae03a63b5a863e8b4d9b6232abb8688f',
  index: undefined,
  hash: '0x8b1065f715f7f93528dcea2b726d976cf8eeddf3689079330737e34cfb0b6d1c',
  type: 2,
  to: '0x5FbDB2315678afecb367f032d93F642f64180aa3',
  from: '0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266',
  nonce: 2,
  gasLimit: 30000000n,
  gasPrice: 849344383n,
  maxPriorityFeePerGas: 203635707n,
  maxFeePerGas: 849344383n,
  maxFeePerBlobGas: null,
  data: '0x6057361d000000000000000000000000000000000000000000000000000000000000004c',
  value: 0n,
  chainId: 31337n,
  signature: Signature { r: "0x351be9ab4359f037abbf2e41c64f13f4c060d64eb6467fd35e42c0133b71234f", s: "0x45b473c2cc793a1a5a6d8cb1482efbda5c90c263196e3475d093ec788ea63bf9", yParity: 1, networkV: null },
  accessList: [],
  blobVersionedHashes: null
}

Querying state

The other function is called retrieve, and it returns the integer value stored in the contract. This is a query of blockchain state, so we don’t need to send a transaction:

> await storage.retrieve();
76n

Because queries only read state and don’t send a transaction, there is no transaction hash to report. This also means that using queries doesn’t cost any Ether, and can be used for free on any network.

Wrapping up

We've created a minimal smart contract and deployed it to a local blockchain instance to demonstrate how we can write and read values from the blockchain. If you found this article helpful, please give it a like and/or a share.

Please feel free to comment with suggestions or corrections you see fit. I write these articles before and after work, I get them out as quickly as I can.

Thanks!

Reference:
Hardhat docs

From Zero to Secured with Iridium and your Next.js App

Josh Fischer — Tue, 19 Sep 2023 20:26:53 +0000

Introduction

We are excited to get Iridium’s newest release out, 0.2.2. While we are still in beta, we are rapidly enhancing our security and working to improve the experience of implementing security for developers everywhere.

Getting Started with Iridium

To initiate the process, head over to the Iridium management UI by visiting https://iridium.software. There, you can opt to log in through GitHub or Google, depending on your preference. After granting the necessary authorizations, you'll be redirected back to the Iridium UI.

Creating a Tenant

Begin by selecting the "Create Tenant" button. A modal will appear, prompting you to input a unique tenant name that adheres to URL-friendly conventions.

This tenant name will serve as the subdomain for your users' authentication. For instance, if you choose "my-tenant" as your tenant name, you will access your application through https://my-tenant.iridium.software.

When it comes to the environment selection, opt for "sandbox" for now.

Configuring the Login Box

To set up user authorization, you'll need to set up the login box. Click on the "Setup Login Box" option, which will allow you to configure login options for your users. In this example, we'll focus on enabling GitHub as the login provider.

By clicking the "Add Provider" box, a modal will appear. Choose "GitHub" as the provider and provide your GitHub OAuth application credentials.

Registering Your Application

Navigate to "Application Management" from the side menu. There, you can select "Create Application." Fill in the necessary details as prompted by the modal that appears and finally hit "submit".

Application Name: This can be any name you choose, e.g. my-next-js-app
Homepage URL: http://localhost:3000
Description: this field is optional
Authorization Callback URL: http://localhost:3000/callback

Make sure to save the generated client ID, as it will be required for future reference.

Integrating Iridium with Your Next.js Application

Now it's time to integrate Iridium into your Next.js application. Begin by cloning the Iridium Next.js starter application using the following commands:

$ git clone git@github.com:IridiumIdentity/iridium-nextjs-example.git
$ cd /iridium-nextjs-example

Create a .env.local file and open it for editing:

$ touch .env.local
$ vim .env.local

Ensure that your .env.local file resembles the following configuration, substituting properties as applicable.

NEXT_PUBLIC_IRIDIUM_DOMAIN=http://YOUR_TENANT_NAME_HERE.iridium.software:8381/
NEXT_PUBLIC_IRIDIUM_REDIRECT_URI=http://localhost:3000/callback
NEXT_PUBLIC_IRIDIUM_CLIENT_ID=YOUR_CLIENT_ID_HERE

Replace YOUR_TENANT_NAME_HERE with the tenant name you created earlier and YOUR_CLIENT_ID_HERE with the application ID Iridium generated for you.

Running Your Secured Application

Now it's time to run your application. Execute the following commands:

$ npm install && npm run dev

Access your application by navigating to localhost:3000 and selecting "Login" at the top right of the screen.

User Authorization Flow

Upon clicking "Login," you'll be seamlessly redirected to your personalized login domain. Choose "Login With GitHub" to initiate the process. This action will take you to GitHub, where you'll see application-specific details.

Select "Authorize ${your-github-name}" to grant authorization. You'll then be redirected back to your Next.js application, if successful, by a confirmation of successful authorization.

Conclusion

Congratulations on successfully implementing Iridium to secure your Next.js application!

Remember, this project is continually evolving, and your insights can contribute to its growth. Feel free to contact me directly at josh@iridium.software or my Co-Founder, Gianni at gianni@iridium.software with any questions.

Finally! Join our growing Iridium community on GitHub discussions or Discord.

-GitHub Discussions
https://github.com/orgs/IridiumIdentity/discussions
-Discord
https://discord.gg/2TMwHF2TrS

Iridium 0.1.4 is released and 100% open-source!

Josh Fischer — Fri, 16 Jun 2023 13:13:37 +0000

We're thrilled to announce the open-source release of our Next-Gen Customer Identity and Access Management System (CIAM)! As we embark on this exciting open-source journey, we invite you to join our community and help shape the future of identity management.

Our objective is to simplify and enhance the developer experience by transforming the way we handle identities. We highly value your expertise and active participation in bringing this vision to life. Let's join forces to create a vibrant community that promotes collaboration and fosters innovation in the realm of identity management.

Key Features:
OAuth 2.x Compatibility: Our system seamlessly integrates with OAuth 2.x protocols, ensuring support for the current state of identity management.

GNAP Ready: We're paving the way for the future by supporting the next generation of identity management systems, powered by GNAP (Grant Negotiation and Authorization Protocol).

Why join us?

Your expertise matters: Contribute your coding skills to enhance our Identity Management System, shaping its growth and functionality.

Test, test, test: Help us identify and resolve bugs by actively testing the system in different environments. Your feedback is crucial.

Spread the word: Share the news of our open-source release with your developer networks, amplifying interest and attracting contributors.

Active participation: Engage in our community discussions, forums, and mailing lists. Collaborate with like-minded developers, sharing insights, and building the future of identity management.

Documentation heroes: Assist in creating comprehensive documentation, ensuring ease of use for newcomers.

We are at the beginning of our open-source journey, and your involvement is crucial. Let's work together to create a secure, scalable, and user-centric identity management system.

To learn more, visit our website, https://docs.iridium.software/0.1.4/, and explore our repository on GitHub at https://github.com/IridiumIdentity/iridium. Join us now, and be part of our growing community of passionate developers!

Thank you for your support and commitment to revolutionizing identity management!

Handling Failures in Streaming Jobs

Josh Fischer — Wed, 11 Aug 2021 15:15:40 +0000

The following article is an except from my forthcoming book Grokking Streaming Systems from Manning Publications. You can find it here.

The reason for streaming systems increasingly being used is the need for on demand data, and on demand data can be unpredictable. Components in a streaming system or the dependent external systems might not be able to handle the traffic and also, they might have their own issues occasionally. Let’s look at a few potential issues that could arise in the fraud detection system.

After all, failure handling is an important topic in all distributed systems and our fraud detection system is no
different. Things can go wrong and safety nets are important to prevent problems from arising.

New concept: backpressure

When the capacity utilization reaches 100%, things become more interesting. Let’s dive into it using the fraud detection job as an example.

When the instance becomes busy and can’t catch up with the incoming traffic, its incoming queue is going to grow and run out of memory eventually. The issue will then prop- agate to other components and the whole system is going to stop working. Backpressure is the mechanism to protect the system from crashing.
Backpressure, by definition, is a pressure that is opposite to the data flowing direction: from downstream instances to upstream instances. It occurs when an instance can not process events at the speed of the incoming traffic, or in other words, when the capacity utilization reaches 100%. The goal of the backwards pressure is to slow down the incoming traffic when the traffic is more than the system can handle.

Measure capacity utilization

Backpressure should trigger when the capacity utilization reaches 100%, but capacity and capacity utilization are not that easy to measure or estimate. There are many factors that decide the limit of how many events an instance can handle such as the resource, the hardware, and the data. CPU and memory usage is useful but not that reliable to reflect capacity either. We need a better way, and luckily, there is one.
We have learned that a running streaming system is composed of processes and event queues connecting them. The event queues are responsible for transferring events between the instances, like the conveyor belts between workers in an assembly line. When the capacity utilization of an instance reaches 100%, the processing speed can’t catch up with the incoming traffic. As a result, the number of events in the incoming queue of the instance starts to accumulate. Therefore, the length of the incoming queue for an instance can be used to detect whether the instance has reached its capacity or not.
Normally the length of the queue count should go up and down within a relative stable range. If it keeps growing, it is very likely the instance has been too busy to handle the traffic.

In the next few pages, we will discuss backpressure in more detail with our local streamwork engine first to get some basic ideas, and then we will move to more general distributed frameworks.
Note that backpressure is especially useful for the temporary issues, such as instances restarting, maintenance of the dependent systems, and sudden spikes of events from sources. The streaming system will handle them gracefully by temporarily slowing down and resuming afterwards without user intervention. Therefore, it is very important to understand what backpressure can and cannot do, so that when system issues happen, you have things under control.

Backpressure in the streamwork engine

Let’s start from our own streamwork engine first since it is more straightforward. As a local system, the streamwork engine doesn’t have complicated logic for backpressure. However, the information could be helpful for us to learn backpressure in real frameworks next.
In the streamwork engine, blocking queues(queues that can suspend the threads that try to append more events when the queue is full, or take elements when the queue is empty) are used to connect processes. The length of the queues are not unlimited. There is a maximum capacity for each queue and the capacity is the key for backpressure. When an instance can’t process events fast enough, the consuming rate of the queue in front of it would be lower than the insertion rate. The queue will start to grow and become “full” eventually. Afterwards, the insertion will be blocked until an event is consumed by the downstream instance. As the result, the insertion rate will be slowed down to the same as the event processing speed of the downstream instance.

Backpressure in the streamwork engine: propagation

Slowing down the event dispatcher isn’t the end of the story. After the event dispatcher is slowed down, the same thing will happen to the queue between it and the upstream instances. When this queue is full, all the instances of the upstream component will be affected. In the diagram below, we need to zoom in a little more than normal in order to see the blocking queue in front of the event dispatcher that is shared by all the upstream instances.

When there is a fan-in in front of this component, which means there are multiple direct upstream components for the downstream component, all these components will be affected because the events are blocked to the same blocking queue.

Our streaming job during backpressure

Let’s look at how the fraud detection job is affected by backpressure with our streamwork engine, when one score aggregator instance has trouble catching up with the incoming traffic.
At the beginning, only the score aggregator runs at a lower speed. Later, the upstream analyzers will be slowed down because of the backpressure. Eventually, it will bog down all your processing power, and you’ll be stuck with an under-performing job until the issue goes away.

Backpressure in distributed systems

Overall, it is fairly straightforward in a local system to detect and handle backpressure with blocking queues. However, in distributed systems, things are more complicated. Let’s discuss them in two steps:

Detecting busy instances
Backpressure

Detecting busy instances

As the first step, it is important to detect busy instances so that the systems can react proactively. We have mentioned in chapter 2 that the event queue is a widely used data structure in streaming systems to connect the processes. Although normally unbounded queues are used, monitoring the size of the queues is a convenient way to tell if an instance can keep up with the incoming traffic or not. More specifically, there are at least two different units of length we can use to set the threshold:

The number of events in the queue
The memory size of the events in the queue

When the number of events or the memory size reaches the threshold, there is likely some issue with the connected instance. The engine declares a backpressure state.

Backpressure state

After backpressure state is declared, similar to the streamwork engine, we would want to slow down the incoming events. However, this task could often be much more complicated in distributed systems than in local systems, because the instances could be running on different computers or even different locations. Therefore, streaming frameworks typically stop the incoming events instead of slowing them down to give the busy instance room to breathe temporarily by:

Stopping the instances of the upstream components or..
Stopping the instances of the sources Although much less popular, we would also like to cover another option later in this chapter: dropping events. This option may sound undesirable, but it could be useful when end to end latency is more critical and losing events is acceptable. Basically, between the two options, it is a trade-off between accuracy and latency. The two options are explained in the diagram below. We’ve added a source instance to help with explanations, and left out the details of some intermediate queues and event dispatchers for brevity.

Backpressure: stopping the sources

Performing a stop at the source component is probably the most straightforward way to relieve backpressure in distributed systems. It allows us to drain the incoming events to the slow instance as well as all other instances in a streaming job, which could be desirable when it is likely that there are multiple busy instances.

Backpressure: stopping the upstream components

Stopping the incoming event could also be implemented at the component level. This would be a more fine-grained way (to some level) than the previous implementation. The hope is that only specific components or instances are stopped instead of all of them and that the backpressure can be relieved before it is propagated widely. If the issue stays long enough, eventually the source component will still be stopped, Note that this option can be relatively more complicated to implement in distributed systems and has higher overhead.

Relieving backpressure

After a job is in a backpressure state for a while and the busy instance has recovered (hopefully), the next important question is: what is the end of a backpressure state so that the traffic can be resumed?
The solution shouldn’t be a surprise as it is very similar to the detection step: monitoring the size of the queues. Opposite to the detection in which we check if the queue is “too full,” this time we check if the queue is “empty enough,” which means the number of events in it has decreased to be below a low threshold, which means it has enough room for new events now.
Note that relieving doesn’t mean the slow instance has recovered. Instead, it simply means that there is room in the queue for more events.

One important fact to keep in mind is that backpressure is a passive mechanism designed for protecting the slow instance and the whole system from more serious problems (like crashing). It doesn’t really address any problem in the slow instance and make it run faster. As a result, backpressure could be triggered again if the slow instance still can’t catch up after the incoming events are resumed. We are going to take a closer look at the thresholds for detecting and relieving backpressure first and then discuss the problem afterwards.

You can read the rest of this material in the book Grokking Streaming Systems. You can find it here: https://www.manning.com/books/grokking-streaming-systems.