[Music] Hello everyone and thank you for joining. Archology is a blockchain network built to improve scalability through true parallel execution while still maintaining full EVM equivalence. In this tutorial, I'll explain what Archology is, highlight some of its key features, and show you how to start an Archology DevNet. Together, we'll write a concurrent smart contract, compile it, deploy it on the DevNet, and send a few test transactions. Archology is a sophisticated system, and it's hard to cover everything in detail in a short tutorial.
The goal here is to give you a quick walk through so you can explore the system further and start building truly scalable contracts that take full advantage of Archy's parallel processing. And hopefully it will inspire you to think outside the box as you design the next generation of scalable applications. So why does scalability matter? A highly scalable blockchain makes all the difference. High performance means lower and more predictable fees, more applications, a better user experience, and ultimately mass adoption.
Take finance for example. One of blockchain's biggest opportunities is to rebuild a decentralized financial system entirely onchain. But that can only happen if scalability is there. The blockchain needs to be fast and efficient enough to compete with today's centralized systems. That's why scalability is such a critical requirement.
So what is Archology? Archology is a parallel blockchain. Its execution engine can process multiple transactions at once while most others are stuck handling just one. Most blockchains process transactions one by one like cars driving down a single lane road. It works but under heavy traffic everything slows down.
Archology takes a different approach with parallel execution. Transactions run side by side like traffic flowing across a multi-lane highway. That's how Archology can handle much higher throughput. Archology is also fully EVM equivalent, which means anything that runs on Ethereum will run on Archology without changes. But Archology goes further.
It gives developers special tools to unlock the full power of parallel execution. And when you use these tools properly, your contracts can run hundreds, even thousands of times faster than on traditional platforms. Our execution system is made up of several modules. First, there's theuler. It organizes incoming transactions and dispatches them to different execution units.
Next, we have the execution units or EU. Each EU runs a standard EVM plus extra modules for concurrency. Inside there's a write cache that holds all state updates during execution. Since the EVM relies on the state DB interface to access data, we built a state DB adapter that redirects all reads and writes into the local cache. That way, each EU works on its own copy during execution.
The EU also includes a module for handling calls to the concurrent library so developers can write contentionfree contracts. We'll dive deeper into that library later. When execution completes, all the read and write logs from every EU are sent to the conflict detector. This checks if multiple transactions tried to access the same state at the same time. Non-conlicting results are committed to the global state while conflicting ones are rolled back to maintain consistency.
And finally, once everything is resolved, all updates are written to our dual storage system. We designed this because parallel execution puts far more stress on the original storage design than it could ever handle. The dual storage system makes sure Archology can keep up with the much higher throughput. So what exactly is contract parallelization? And if Archology is fully EVM equivalent, why do we even need it?
Here's the answer. Yes, all existing Ethereum contracts can run on Archology, but only about half of them can actually benefit from parallel execution because they weren't designed with concurrency in mind. There's a common misconception that once you have a parallel execution engine, you automatically get a 100 or even a thousand times faster. That's not true. The speed up only comes when contracts are designed to run in parallel.
It's those parallelized contracts that can really unlock that level of performance. Calling sequential only contracts in parallel only trigger roll backs or reversions. It's the only way to protect the blockchain state. In short, contract parallelization in Archology means using Archy's tools to optimize sequential only contracts so they can fully take advantage of parallel execution without suffering throughput penalties. Now we know why parallelization is necessary.
The next question is how do we actually do it? The biggest challenge in parallel execution usually isn't running things at the same time. That part is often straightforward. The real challenge is protecting shared data. When you run transactions in parallel, threads and processes often touch the same piece of data.
Without controls, those updates can collide, causing errors and breaking the contract state. Think of it like a shared document. If two people try to edit the same line at once, you end up with a mess. In traditional programming, you'd solve this with concurrency primitives like a lock. Whenever you need to access shared data, you lock it so no one else can touch it until you're done.
On blockchain, though, that approach doesn't work. While safe and simple, locks aren't deterministic. And determinism is absolutely critical for blockchain consensus. That's where Archy's concurrent library comes in. It provides of solidity tools and data structures that let developers manage shared state safely, take full advantage of parallel execution and still guarantee deterministic results.
Now, let us work through some key components of the concurrent library. For example, cumulative variables only accept delta updates. You can increase or decrease them, but you can't just overwrite the value. They're perfect for things like tracking the total supply in an ERC20 token. Then there are concurrent containers.
These are drop-in replacements for Solidity's native data structures, but with one big difference. They support safe, concurrent updates. And finally, there's the multipprocessor. It lets you spin up EVM instances programmatically just like spawning threads in a traditional programming language. That means you can design contracts to fully leverage parallel execution.
You'll find everything you need on Archy's doc site. The technical white paper, system structure, workflow, concurrency design, and of course, the concurrent programming guide. The main page gives you a high-level overview of Archology, what it is, how it's different, and the core technologies that make it fast. You'll also find links to key sections so you can explore the platform in more depth. Among them, the parallel execution document covers all the main aspects of Archy's parallel engine, its design philosophy, concurrency control strategies, technical choices, and major modules, and how they all work together.
If you want to understand how Archy's parallel design works behind the scenes, this is the place to start. For contract developers, you probably want to spend more time on the concurrent programming guide, which covers the key information for using Archy's library to write concurrent smart contracts on our platform. Cumulative integers are great for concurrent delta updates. They're perfect for tracking totals where you need to add increments from multiple transactions at the same time. Think of them like atomic variables in other programming languages.
Always safe to update even under heavy concurrency. Concurrent arrays are drop-in replacements for Ethereum's native arrays. They are threads safe and deterministic. They allow multiple transactions appended safely in parallel. In archology, maps are thread safe ordered maps.
They let you iterate in a fixed order, retrieve by index, verify keys, and choose between in-memory, blockbound, or in storage modes. You might be curious how these thread safe structures are actually built. The secret is a primitive hybrid container, the core building block for concurrency. If you'd like the deep dive, the document explains it in detail. Multiprocessor lets you spawn parallel EVM instances.
Much like starting new threads in other languages, the document includes simple examples to get you started. The runtime package comes with handy tools like a deterministic random number generator and other utilities. If you want hands-on experience with your first concurrent contract, go to the run the example page. The guide walks you step by step through setting up Archy's DevNet, deploying a simple parallel contract, and running a test all in just a few minutes. It feels just like deploying on Ethereum since Archology is fully EVM compatible and uses standard Ethereum tools.
First, let's check your setup. You'll need node, yarn, docker, vscode, or remix if you prefer, plus the archology devet container. For hardware, plan on at least four cores, 16 gigs of RAM, and 100 gigs of free space. And if you're benchmarking, you'll want something much more powerful. You can copy and paste most of the commands straight from the document.
I'll be using Ubuntu for this demo, but Mac OS should work just fine. First, save your machine's local IP address into an environment variable so your tools can connect later. Archology provides DevNet as a Docker container. It gives you a local blockchain environment to work with. Now, pull down the Archology DevNet image from DockerHub and start it.
Since I'm on Linux, I'll need to put pseudo in front of the command. Pulling the Docker image may take a while depending on your internet speed. Once it's downloaded, the DevNet will start up. Now, let's check if the Docker image is running correctly. To make sure DevNet is running properly, start by installing Archy's front-end tools.
They include a lightweight network monitor you can use to check the status. Now connect the monitor to your DevNet to see live stats of the network. The DevNet might take a few minutes to fully start. If you don't see the correct messages at first, just try again after a couple of minutes. When the block height begins incrementing, that means the network is up and running.
Next, clone the examples repo from GitHub. It's packed with handy samples to get you up and running fast. inside the repo. You'll see several subfolders. The account folder contains accounts with private keys, addresses, and initial balances.
Usually, you don't need to change anything here. Let's start with the scaffold folder. It has simple parallel contracts to build on and is a great way to get a feel for Archology. Inside, open network.json and replace the URL with your DevNet IP.
So, the test script connects. Then, save the changes back to the configuration file when you're done. Now we need to set up the test. Use HTTPS instead of SSH and get to skip authentication if needed. Next, install the dependencies.
Finally, we run the test script. It compiles your contract, deploys it, sends transactions, and checks the results. The whole process may take a couple of minutes. If everything's set up right, you'll see no errors. There's also a benchmark folder with scripts and data for generating transaction batches.
I won't run them here since it takes time, but you can follow the docs to try it yourself. Just keep in mind Archy's multi-threaded design really pushes hardware. A normal dev machine won't show its full potential, but feel free to give it a try. Let's take a closer look behind the scenes. The test we ran compiled a contract called like, a simple tracker that counts how many times the like function is called.
Each call increments the total by one. On a normal sequential EVM, this works fine. The value goes up step by step as transactions are processed. But in a parallel environment, if multiple calls happen at the same time, updates can clash and some increments may be lost and the counter would show the wrong total. This is the classic concurrency problem and it's exactly what our collegey's cumulative counters are designed to solve.
In the parallel version, we import a concurrent variable from Archy's library and initialize it with lower and upper bounds. If an increment goes beyond the limit, the transaction reverts. This variable is deterministic, atomic, and thread safe. So even if hundreds of users call the function at the same time, every increment is merged correctly. There are more examples too.
One is a parallelized unis swap v3 that can handle concurrent calls to the same pool even between the same users. Something that would break every other parallel system. This version also tackles big issues in the original design like slippage and front running. Archology solves it with a netting layer. Transactions first go to the netter in parallel where opposite trades cancel out and only the net difference reaches the pool.
That boosts throughput, reduces load, improves liquidity efficiency, and makes sandwich attacks impossible because the attacker's own trades cancel before they ever reach the pool. You can think of it as a hybrid model combining an onchain order book with an AMM. And importantly, all of Uniswap V3's original features remain unchanged. You can dive into the examples to see all of Archy's concurrent features. This one's more advanced, really aimed at power users.
Thank you for watching. Feel free to reach out to our team if you have any questions. [Music]
Automatic transcript — names and jargon may be misspelled.