DEV Community: Lau!

Developer Journal Day6: Business Blockchain

Lau! — Sun, 14 Jun 2026 21:10:05 +0000

The global AI market already exceeds $2.5 trillion in estimated spending for 2026. But what's interesting isn't just the size of the number — it's what companies are actually looking for today: not specialists in a single technology, but people capable of combining AI, Cloud, Blockchain, security and automation. That integration vision isn't new. There were projects that tried to combine AI and Blockchain long before it became trendy, and it's worth looking at what happened to them, because what they built — and what they failed to achieve — is still relevant today.
Although blockchain is a much smaller sector than AI, the trend we're seeing is that companies aren't only looking for AI specialists. They're looking for people capable of integrating:

AI
Cloud
Security
Data
Blockchain
Business automation

Sure, AI moves way more money than blockchain by a huge margin. But blockchain remains a strategic technology in areas where trust, auditing, identity, traceability and digital assets are needed. That's why many companies end up needing both instead of choosing one or the other.
DeepBrain Chain is a project I found interesting precisely because it tried to combine two things long before it became fashionable: AI + Blockchain. This idea was born in 2017, with the proposal of creating a decentralized computing power network, mainly GPUs, so that AI companies and developers could rent computational resources cheaper than those from traditional providers.
If you think about it, the concept is pretty similar to what several decentralized computing networks for AI are trying to do today.

So, is it a success?
Its market had a lot of hype during the 2017-2018 crypto boom. Its all-time high was close to $0.66 USD per token — today it sits around $0.0003 USD, more than 99% below that peak.
This doesn't automatically mean the project is a fraud, but it does indicate it never reached the adoption many investors expected, for several reasons:

It arrived too early
The AI market of 2017 was much smaller than today
Decentralized GPU infrastructure was hard to build

It ended up with a pretty damaged reputation within the crypto ecosystem. But the curious thing is that its idea doesn't seem so crazy in 2026.

What happened to Ocean Protocol? Does it still collaborate with car manufacturers?
Ocean Protocol was a fascinating case and yes, it still exists, but it's no longer in the position it held between 2020 and 2024. And the famous collaborations with car manufacturers don't seem to be the center of the story today.
Ocean wanted to create a decentralized data economy — a very brilliant idea, since companies own data, don't want to sell it completely, but do want to monetize it. Ocean allowed data access while maintaining a certain level of control and privacy.
That's how it caught the attention of industrial and automotive sectors. It participated in initiatives like Catena-X alongside companies from the European automotive ecosystem and organizations like Bosch and Fetch.ai.
When you think about supply chain, traceability, predictive maintenance or connected vehicles, that's where Ocean made sense.
With the AI boom, Ocean got very close to these projects, giving birth to what became known as the Artificial Superintelligence Alliance (ASI). The idea was to unite AI + Blockchain ecosystems under a common vision, and at that moment a lot of people thought:
"They're building the decentralized infrastructure for the AI economy"

And here comes the twist.
In 2025, Ocean left the ASI alliance, going back to operating independently. It stated it wanted to regain control of its tokenomics and strategic direction. There were also cross-accusations and governance conflicts among the participants.
The interesting thing is that Ocean hasn't disappeared. The project's own documentation still describes Ocean as an independent token after the ASI exit, and the team continues developing a vision around decentralized data and AI.
In crypto communities there are still people who see it as a historical data infrastructure project for AI that's trying to reinvent itself after the break with ASI.
Its original idea remains extremely powerful — and not because it's a cryptocurrency, but because it raises a question that companies still haven't fully resolved:

"How do you share data between organizations without losing control over it?"

From the technical side, there are concrete answers: Hyperledger, APIs, messaging systems, Smart Contracts coded to unlock information only with the private key of whoever is meant to receive it. The tools exist. But The Matrix Revolutions left us something in one of the last dialogues between The Oracle and The Architect: technical problems tend to be hard, but human problems tend to be even harder. And in the business world, sharing data between organizations isn't just a technical problem. It's a problem of trust, incentives, governance and interests that don't always align. That's where projects like Ocean Protocol tried to build something that goes beyond the code.

I wouldn't say Ocean Protocol revolutionized the automotive industry, but it was one of the projects that helped popularize the idea of decentralized data markets and data sharing between companies — something with very important applications in the automotive sector.

And finally, let's talk about the Cortex project
Because it was one of those projects that, when it appeared, seemed like science fiction. Its proposal was:
"What if Smart Contracts could execute artificial intelligence models directly inside the blockchain?"
In 2018 that was an idea very ahead of its time. Cortex wanted to upload AI models to the network, execute inferences inside the blockchain, enable smart contracts with AI capabilities, and create AI DApps — better understood as decentralized applications with integrated AI.
They claimed to be the first blockchain capable of supporting on-chain AI, and in terms of marketing and architecture, they had a basis for that claim. Even today Cortex still describes itself as the first — and according to them, the only — public blockchain capable of executing AI inference directly on-chain.
Now imagine a smart contract that asks:

Does that transaction look fraudulent?
Was the payment received?
Did the goods arrive before the deadline?

But those questions are answered by the smart contract itself without needing AI — it just has to be fully configured, or in other words, the rules have to be defined.
And that's one of the reasons why thousands of AI+Blockchain projects ended up having less impact than they promised.
Everything can be programmed with traditional logic. AI starts to make sense when the answer can't easily be expressed through rules — for example, when probabilistic inference is involved.
Cortex still exists as an active project and its documentation still claims the title of first public blockchain capable of executing AI inference on-chain. But it never reached mass adoption, partly because it arrived too early and partly because the problem it was trying to solve turns out to be unnecessary in most real-world cases. Smart contracts don't need a classification model to know if a payment was received. Traditional logic handles that perfectly. Cortex found the right answer to a question very few companies were asking.

Many times, especially in blockchain and AI, a tendency appears to think that if a technology is good, it should do everything.
In a symphony orchestra, nobody says: the violin is so good it should replace the piano, or percussion is so important that all music should be percussion.
Every instrument has strengths and limitations — and it's the same with technology. Blockchain is excellent for trust, traceability, auditing and coordination between actors. Traditional databases are excellent for speed and massive storage. AI is excellent for classification, prediction and analysis. APIs are excellent for integration. Cloud is excellent for scalability. Messaging systems are excellent for communication between services.

[Boost]

Lau! — Sat, 30 May 2026 16:23:07 +0000

Lau!

May 30

Developer Journar Day5: 🚀 How to Launch and Configure an Amazon EC2 Instance (From Scratch)

#ec2 #aws #cloudcomputing #devops

2 min read

Developer Journar Day5: 🚀 How to Launch and Configure an Amazon EC2 Instance (From Scratch)

Lau! — Sat, 30 May 2026 07:28:51 +0000

When you start working with cloud computing on AWS, one of the first major milestones is understanding how EC2 instances work. In simple terms, it’s like spinning up your own server on the internet in just a few minutes.

In this article, I’ll walk you through how to create and launch an EC2 instance that works as a basic web server.

🧠 What is an EC2 instance?

An instance in Amazon Web Services, specifically within the Amazon EC2 service, is a virtual machine that you can configure based on your needs: CPU, memory, storage, and operating system.

Think of it as renting a computer in the cloud that you can start, stop, and customize anytime.

⚙️ Step 1: Create the instance
The first step is to go to the EC2 dashboard and click “Launch Instance.”

Here you define some key settings:

🏷️ Instance name

You can assign a descriptive name such as:

“My Web Server”

This helps you easily identify it later.

🧩 Step 2: Choose the AMI

An Amazon Machine Image is basically the base image used to create your server.

In this case, we use Amazon Linux, a lightweight and optimized OS for cloud environments.
**
🖥️ Step 3: Instance type**

This defines the computing power of your virtual machine.
For this example:

t3.micro
1 vCPU
1 GB RAM
Free Tier eligible This is perfect for learning and small projects.

🔐 Step 4: Key pair (SSH access)

To securely connect to your instance, you need a key pair:

🔑 Public key: stored in the instance
🔒 Private key: kept on your machine
This enables secure SSH access.

🌐 Step 5: Network settings

Here you control how your instance is accessed.

In this setup:

HTTPS traffic is allowed from the internet
A Security Group is used to manage inbound rules

This is what makes your server accessible from a browser.

💾 Step 6: Storage configuration

You assign virtual disk storage (EBS):

8 GB
gp3 volume type Enough for a basic web server setup.

🧾 Step 7: User Data script (bootstrapping the server)

The base AMI only includes the operating system, so no web server is installed by default.

To fix this, we use User Data, which allows us to run a script at launch time that:

Installs a web server (like Apache or Nginx)
Starts and enables the service automatically
Prepares the instance to serve web content

🚀 Step 8: Launch the instance

Once everything is configured:
👉 Click “Launch Instance”

AWS handles the rest: provisioning, setup, and booting your virtual machine.

🌍 Step 9: Access your server

After a couple of minutes, the instance will be in a running state.

Then:

Copy the public IP address
Open a browser
Paste the IP

And you’ll see your web server running 🎉

🎯 Conclusion
Launching an EC2 instance is one of the first essential steps in understanding cloud computing on AWS.

With just a few clicks, you can deploy a fully functional virtual server ready to host applications, APIs, or websites.

If you want, I can also help you next with:

adding AWS architecture diagrams
explaining VPC, subnets, and security groups visually
or turning this into a “Cloud Engineer roadmap series” post

Just tell me 👍

Developer Journal day4..Deploying a Hyperledger Fabric Network on Kubernetes — From Zero to Production-Ready published

Lau! — Sun, 17 May 2026 05:35:38 +0000

Blockchain infrastructure is hard. Running it on Kubernetes is even harder. In this article I'll walk you through how I built a production-ready Hyperledger Fabric network on Kubernetes, including automated deployment scripts, network configuration, and the security decisions I made along the way.

🧠 Why Hyperledger Fabric + Kubernetes?
Hyperledger Fabric is the go-to permissioned blockchain framework for enterprise use cases — supply chain, financial services, healthcare. Unlike public chains, you control who participates.
Kubernetes brings what Fabric alone can't give you out of the box:

Self-healing — pods restart automatically on failure
Scalability — spin up more peers as needed
Declarative infrastructure — everything is a manifest
Namespace isolation — clean separation between components

The combination is powerful, but the learning curve is steep. Here's what I built and what I learned.

🏗️ Architecture Overview
The network consists of:
ComponentRoleOrdererOrders transactions and creates blocks (RAFT consensus)PeersEndorse and commit transactions, host the ledgerCA (Certificate Authority)Issues identities for all participantsKubernetes JobsHandle one-time setup tasks (channel creation, chaincode install)
All components live inside a dedicated fabric namespace in Kubernetes, with strict network policies controlling traffic between them.

📁 Project Structure
fabric-k8s/
├── manifests/
│ ├── orderer/
│ ├── peers/
│ ├── ca/
│ └── jobs/
├── scripts/
│ ├── deploy.sh # Main entrypoint
│ └── utils.sh # Helpers: logging, wait functions
├── config/
│ └── configtx.yaml # Network genesis config
└── .env.example # Environment template (no secrets committed)

⚙️ Automated Deployment Scripts
One of the things I'm most proud of in this project is the deploy automation. Rather than running kubectl apply commands manually and hoping for the best, I built a script system with proper logging, error handling, and readiness checks.
Logging with Color
bashRED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
CYAN='\033[0;36m'
NC='\033[0m'

info() { echo -e "${GREEN}[INFO]${NC} $1"; }
warn() { echo -e "${YELLOW}[WARN]${NC} $1"; }
step() { echo -e "\n${CYAN}▶ $1${NC}"; }
error() { echo -e "${RED}[ERROR]${NC} $1"; exit 1; }
Simple but effective — every log line is color-coded by severity, so you know at a glance what's happening during a deploy.
Waiting for Deployments
One of the trickiest parts of Kubernetes automation is knowing when something is actually ready. I wrote a waitDeployment() function that uses kubectl rollout status with a timeout:
bashwaitDeployment() {
local NAME=$1
info "Waiting for deployment/$NAME..."
kubectl rollout status deployment/"$NAME" \
-n "$NAMESPACE" --timeout=120s || error "Timeout on $NAME"
}
Waiting for Jobs
Channel creation and chaincode installation run as Kubernetes Jobs. These need their own wait logic:
bashwaitJob() {
local NAME=$1
info "Waiting for job/$NAME..."
kubectl wait job/"$NAME" \
-n "$NAMESPACE" \
--for=condition=complete \
--timeout=300s || {
warn "Job $NAME timed out. Checking logs..."
kubectl logs -n "$NAMESPACE" -l app="$NAME" --tail=50
error "Job $NAME failed"
}
}
Notice that on failure, it automatically dumps the last 50 lines of logs — no need to manually kubectl logs when something breaks at 2am.

🔐 Network Configuration — The Orderer
The orderer is the most critical component: it's the one that decides the order of transactions across the entire network. I used RAFT consensus (as opposed to the deprecated Solo mode) which means multiple orderer nodes vote on block ordering.
Key configuration decisions:

TLS enabled on all orderer-to-peer communication
Mutual TLS (mTLS) for admin operations
Resource limits set to prevent one noisy component from starving others
Persistent volume for the ledger data (not ephemeral storage)

📦 Kubernetes Manifests
Each component has its own manifest directory. An example of the security-conscious securityContext I applied to every pod:
yamlsecurityContext:
runAsNonRoot: true
runAsUser: 1000
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
No pod runs as root. No pod can escalate privileges. This is table stakes for anything production-adjacent.
Network Policies
Every component is locked down with NetworkPolicy — only the pods that need to talk to the orderer can reach it:
yamlapiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: orderer-ingress
namespace: fabric
spec:
podSelector:
matchLabels:
app: orderer
ingress:
- from:
- podSelector:
matchLabels:
role: peer
ports:
- port: 7050

🔒 Security Decisions
A few things I was deliberate about:

No secrets in the repo — certificates, keys, and passwords are loaded from environment variables and Kubernetes Secrets, never committed to Git.
.env.example pattern — I commit a template with empty values so collaborators know what's needed without exposing real data.
Private repository — the repo stays private; only collaborators with explicit access can see it.
Pre-deploy validation — the script checks for kubectl availability and cluster connectivity before touching anything.

bashwhich kubectl > /dev/null 2>&1 || error "kubectl not found"
kubectl cluster-info > /dev/null 2>&1 || error "No cluster connection"
Fail fast, fail loud.

🧗 Challenges & What I Learned
Crypto material management is the #1 pain point in Fabric. The cryptogen tool generates a mountain of certificates and keys, and keeping track of which cert goes where (and making sure they match between components) took significant debugging time.
RAFT leader election surprised me — during initial setup, if the orderer pods don't all come up within the election timeout, the network never bootstraps. Adding proper readiness probes and the waitDeployment() timeout logic solved this.
Kubernetes Jobs for one-time operations (channel creation, anchor peer updates) was a pattern I hadn't used much before. It's elegant — idempotent, tracked by Kubernetes, with built-in retry logic.

🚀 What's Next

Add Prometheus + Grafana dashboards for peer/orderer metrics
Implement Sealed Secrets or Vault for crypto material management
Write chaincode in Go and deploy it through the pipeline
Add CI/CD with GitHub Actions to automate manifest linting and test deploys

💬 Final Thoughts
This project pushed me across infrastructure, cryptography, distributed systems, and DevOps simultaneously. If you're exploring enterprise blockchain or want to see how Fabric actually runs in a cloud-native environment, I hope this breakdown gives you a useful starting point.
The full project (minus secrets, of course) is on my GitHub. Feel free to open an issue or reach out if you have questions.

Developer Journal Day3.. 🏎️ On-Chain vs Off-Chain Payments for a VIP Car Collection Platform — What would you choose?

Lau! — Tue, 12 May 2026 16:29:08 +0000

I'm currently building a mini project focused on a VIP car collection inventory platform
designed for high-end clients who own and manage luxury or classic vehicle portfolios.

One of the most critical architectural decisions right now is defining the payment system.
Since the project is blockchain-oriented and built around Hyperledger Fabric, I'm evaluating
two different approaches and I'd love to hear from the community.

🔵 Option A — Native Token System (On-Chain)

Create a native credit token inside the Fabric network:

Clients deposit real money → tokens are issued to their wallet
Platform services consume those tokens
Think ERC-20 logic, but implemented natively in Hyperledger Fabric
Creates a fully on-chain payment ecosystem

🟢 Option B — Off-Chain Payments + On-Chain Verification

Payments happen externally through traditional methods (Stripe, bank transfer, etc.):

The blockchain only stores a "payment_confirmed" event
A hash of the payment receipt is recorded on-chain for auditability
Keeps the chain lean; complexity lives in proven, off-chain infra

💬 What I'd like feedback on

Which architecture is more realistic for production?
Which offers better scalability and maintainability long-term?
Which would be more attractive to VIP/high-end clients?
Does a fully on-chain payment experience actually add value in this type of app, or is it over-engineering?
From a software engineering perspective — which would you personally choose and why?

Opinions, technical feedback, architecture suggestions, or hybrid alternatives are all welcome.

Drop your thoughts below 👇

Developer journal day2. Building CarVault 🚗

Lau! — Sat, 09 May 2026 23:49:42 +0000

I’ve been working on CarVault, a VIP car collection inventory platform designed for luxury and high-end vehicle collectors.

****** WEB APLICATION ****
https://carvault-1ay8g63.public.builtwithrocket.new

The project combines:

Hyperledger Fabric
Blockchain architecture
Inventory management
Payment systems
Docker infrastructure
Premium UI/UX

Instead of building a traditional inventory system, the goal is to create a secure and auditable platform capable of handling:

Vehicle ownership history
VIP client management
Immutable audit records
Payment verification
Blockchain-based asset tracking

Current architecture direction:

Frontend UI
    ↓
Backend API
    ↓
Hyperledger Fabric
    ↓
Chaincode + Ledger

At the moment, I’m working on:

Hyperledger Fabric integration
Docker network setup
Chaincode structure
Payment architecture research

The current website represents the visual experience and concept design of the platform.

The full technical implementation — including Hyperledger Fabric integration, Docker infrastructure, backend logic, and chaincode development — will be available separately through my GitHub portfolio as the project evolves.

The visual experience will eventually become the frontend connected to the blockchain backend.

This project is still evolving, but it’s becoming an exciting mix of system design, enterprise blockchain, and luxury-tech concepts.

More updates soon.

Developer Journal..“My First Docker + Nginx Setup on Ubuntu”

Lau! — Fri, 08 May 2026 18:59:40 +0000

Hello Everyone!

A while ago, I decided to learn Docker and, honestly, it turned out to be much simpler than I expected. In this article, I’ll walk you through how I configured Docker on Windows using WSL (Windows Subsystem for Linux) and ran my very first container.

If you're a developer using Windows and want to get into Docker, this post is for you.

Spoiler: At the end, you’ll see the Nginx welcome page in your browser — and that feeling is amazing 🎉

What is Docker? (In Simple Terms)

Docker is a platform that allows you to package your application inside a “container” — an isolated and portable environment that behaves the same way on any machine.

Think of it as a sealed box containing everything your app needs to run.

Prerequisites

Before getting started, you’ll need:

✅ Windows 10 or 11
✅ WSL (Windows Subsystem for Linux) enabled
✅ A Linux distribution installed (we’ll use Ubuntu)
✅ PowerShell running as Administrator
Step 1: Verify and Install WSL

WSL allows you to run Linux commands directly on Windows. Let’s first verify whether it’s installed.

Option A: List all available distributions
wsl --list --online

This command will show all Linux distributions available for installation.

Option B: Install Ubuntu on WSL (if you don’t already have it)
wsl --install -d Ubuntu
Option C: Check installed distributions
wsl --list --verbose

This command is very useful because it shows the state and version of each installed distribution.

Step 2: Open Ubuntu in WSL

From PowerShell, type:

wsl -d Ubuntu

You should see something like:

user@PC:~$

Congratulations! You are now inside Ubuntu. From this point on, all commands will be Linux commands.

Step 3: Verify and Install Docker

First, let’s check if Docker is already installed:

docker --version

If Docker is not installed, you’ll see a message suggesting available packages. Install it with:

sudo apt-get install docker.io -y

The -y flag automatically answers “yes” to confirmation prompts, saving time.

Verify the installation
docker --version

You should see something like:

Docker version 24.0.x
Step 4: Enable and Start the Docker Service

Docker is now installed, but we still need to start the service.

Enable Docker to start automatically
sudo systemctl enable docker
Start the service immediately
sudo systemctl start docker
Step 5: Fix Permission Errors

If you encounter an error like this while running Docker commands:

PERMISSION DENIED WHILE TRYING TO CONNECT TO THE DOCKER API AT UNIX:///VAR/RUN/DOCKER.SOCK

Don’t worry! This is completely normal. Docker requires special permissions.

Add your user to the Docker group:

sudo usermod -aG docker your_user

Replace your_user with your Linux username.

Now you have two options:
Option 1 (Recommended): Close and reopen Ubuntu
exit

Then reopen it from PowerShell:

wsl -d Ubuntu
Option 2: Activate the group immediately
newgrp docker
Verify everything works
docker ps

If you see an empty table with headers like CONTAINER ID, IMAGE, etc., Docker is working correctly 🎉

Step 6: Run Your First Container (Nginx)

Here comes the fun part. Let’s run Nginx, one of the most popular web servers:

docker run -d -p 8080:80 nginx
What does this command do?
docker run → Runs a container
-d → Runs it in detached mode (background)
-p 8080:80 → Maps port 8080 on your machine to port 80 inside the container
nginx → The image you want to run (Docker will download it automatically)

You should see something similar to:

Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
...
Digest: sha256:abc123...
Status: Downloaded newer image for nginx:latest
a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

That last string is your container ID.

Your container is now running 🚀

Step 7: Verify the Container is Running
docker ps

You should see your container listed with the status Up.

Step 8: The Best Part — Open it in Your Browser

Open any browser on Windows (Chrome, Firefox, Edge, etc.) and go to:

http://localhost:8080

If everything worked correctly, you’ll see the beautiful Nginx welcome page saying:

“Welcome to nginx!”

That feeling when you realize everything is actually working is incredible 🚀

Additional Useful Commands

Here are a few Docker commands you’ll probably want to know:

View all containers (including stopped ones)
docker ps -a
Stop a container
docker stop CONTAINER_ID
Remove a container
docker rm CONTAINER_ID
View container logs
docker logs CONTAINER_ID
Lessons Learned

✅ WSL is essential: Without WSL, Docker on Windows can feel complicated. With WSL, the experience becomes much smoother.

✅ Permissions matter: “Permission Denied” errors are completely normal. It’s not a broken installation — you just need the correct user group permissions.

✅ Docker is beginner-friendly: The Docker ecosystem has done an excellent job making containerization accessible.

✅ Documentation is your best friend: If something breaks, check the logs using docker logs.

What’s Next?

Now that Docker is working, you can:

Build your own Dockerfile for a personal application
Explore Docker Hub and discover thousands of pre-configured images
Learn Docker Compose for multi-container orchestration
Publish your own images on Docker Hub
Final Thoughts

My first experience with Docker on Windows was honestly great.

The process is clear, well documented, and most importantly — you get immediate results. And that’s one of the best ways to learn.

If you’re thinking about learning Docker:

Don’t wait any longer.

The journey into containerization begins with a simple:

docker run

Have questions? Ran into problems? Share your experience in the comments — I’d love to hear about your first Docker setup too 💙

References & Resources
Docker Official Documentation
WSL Documentation
Docker Hub

Don’t touch Fabric unless you’re ready for distributed headaches 😵‍💫

Lau! — Fri, 08 May 2026 16:02:48 +0000

Building a VIP Vehicle Inventory System with Hyperledger Fabric 🚗

I recently started designing a new blockchain project focused on managing exclusive vehicle inventories for VIP collectors using Hyperledger Fabric.

The idea is to build a permissioned system where verified members, dealers and validators can securely manage high-value vehicle assets, ownership history and inventory access while keeping sensitive data private.

One thing I’m realizing very quickly is that Fabric is very different from typical blockchain development.

At first, concepts like:

MSPs
endorsement policies
peers
orderers
private data collections

felt less like blockchain and more like trying to assemble enterprise IKEA furniture without instructions 😵‍💫

But the deeper I go, the more I understand why enterprise blockchain architecture requires this level of structure and permission management.

Right now I’m focusing on:

defining actors and trust models
modeling business logic
planning chaincode structure
understanding what belongs on-chain vs off-chain

Still early in development, but excited to keep building and documenting the process.

Hyperledger #Fabric #Blockchain #Web3 #SmartContracts