To build any of that, you need the data. And the data you actually need (every trade fill, both sides, every user’s PnL) lives exclusively on S3 in a binary format no existing indexer can read.

I built hypercore-indexer, open source, 450 blocks/sec from S3, HIP4-ready on day one. Contribute !

The HIP4 Data Problem

HIP4 is a dual-layer system. M

• Markets trade as `#`-prefixed coins on HyperCore L1 (`#90` for “Hypurr wins the 100m dash”).
• Deposits, claims, and settlements happen on a HyperEVM contest contract.
• The contest events are standard EVM logs; any indexer with RPC access can get them.

The hard part is the trade data. Every prediction market fill (buyer, seller, price, size, PnL) lives in Hyperliquid’s `node_fills_by_block` S3 dataset. No RPC exposes it. The public `recentTrades` API returns only the last 10 fills with no pagination. This is the data that powers leaderboards. Who’s profitable on HIP4, who’s providing liquidity, who’s the biggest trader: all locked behind S3 in a custom binary format.

What hypercore-indexer Captures

From S3 EVM blocks (also available via RPC, but 200x faster via S3):

1. Contest deposits: who bet on which side, how much
2. Contest claims: settlement payouts
3. Contest creations, refunds, sweeps

From HyperCore API (polled in background):

1. Market metadata: outcome names, sides, descriptions
2. Price snapshots: implied probability every 5 seconds

From S3 node_fills (exclusive, no other path):

1. Every trade fill: both sides, price, size, PnL, fees
2. Per-user realized PnL: the leaderboard dataset

HIP4 is live on testnet now. When mainnet launches, one config change enables everything.

What You Can Build

HIP4 deposits, who bet on what:

SELECT contest_id, side_id, COUNT(*) AS bets,
       SUM(amount_wei) / 1e18 AS total_eth
FROM hip4_deposits
GROUP BY contest_id, side_id
ORDER BY total_eth DESC;

Top traders by realized PnL (from the S3-exclusive fill data):

SELECT user_address,
       COUNT(*) AS trades,
       SUM(CAST(closed_pnl AS NUMERIC)) AS total_pnl,
       SUM(CAST(size AS NUMERIC) * CAST(price AS NUMERIC)) AS volume
FROM fills
WHERE coin LIKE '#%'
GROUP BY user_address
ORDER BY total_pnl DESC
LIMIT 10;

This query is impossible without the S3 `node_fills_by_block` data. No RPC, no API, no other indexer gives you both sides of every HIP4 trade with PnL.

Why S3 Instead of RPC or Nodes?

RPC (self-hosted or managed): ~2 blocks/sec. $200–500/month. You run a Reth fork or pay a provider. Rate limits apply.

Vendors: Managed, but EVM events only (no L1 trade data)

S3 native: 450 blocks/sec. ~$2/month. No node, no subscription, no rate limits. Stateless (the bucket is there, you pay per request).

A full 30M block backfill costs ~$11. S3 is 200x faster and 100x cheaper than running a node. And the `node_fills_by_block` dataset; every trade fill; is S3-exclusive. No RPC serves it.

Two Commands to Start

hypercore-indexer init
hypercore-indexer live

Discovers the chain tip via RPC, starts indexing, follows new blocks with adaptive polling. No config to write, no node to run.

Stop the indexer, restart it later: it picks up exactly where it left off. If it falls behind (e.g., laptop sleeps for an hour), it auto-detects the gap and switches to parallel backfill to catch up, then seamlessly returns to tip-following.

Three storage backends: start with SQLite (zero setup, single file), move to PostgreSQL for production, use ClickHouse when you need sub-second aggregation over millions of rows. Switch by changing one URL in the config.

Or the full HIP4 stack with Docker:

cd examples/live-hip4-clickhouse && docker compose up

ClickHouse + live indexing + HIP4 API poller: all prediction markets with live implied probabilities, updating every 5 seconds.

Architecture

• Crash recovery: cursor and data commit atomically in the same transaction. Restart = resume from last committed block. Idempotent inserts make re-processing safe across all backends.
• Adaptive live mode: polls S3 every ~1 second, matching Hyperliquid’s block time. Backs off when no new block, parallel-backfills when it falls behind. HIP4 event decoding runs after block storage; if it fails, the block is still indexed (fire-and-forget, never blocks core indexing).

Limitations

• No API layer yet: Query the database directly. REST/WebSocket API is next on the roadmap.
• HIP4 positions not indexed: User positions are L1 state, only available via per-user API polling.

What’s Next

API layer (next): Axum REST/WebSocket for leaderboards, position tracking, OHLC candles. The database has the data; the API makes it accessible without SQL. This is the priority.

Real-time streaming: Hyperliquid WebSocket at ~100ms, or QuickNode/Dwellir gRPC at ~20–80ms. Webhooks that fire on every `#`-prefixed trade: whale entry, market settlement, price dislocation. S3 stays the source of truth; real-time adds sub-second detection.

Get Started

# Docker
docker pull ghcr.io/exomonk/hypercore-indexer
docker run --rm -v ~/.aws:/root/.aws:ro ghcr.io/exomonk/hypercore-indexer live

# From source
git clone https://github.com/ExoMonk/hypercore-indexer && cd hypercore-indexer
cargo install --path . && hypercore-indexer init && hypercore-indexer live

Open source PRs welcome, especially for the API layer and real-time streaming

GitHub Repo:

hypercore-indexer

The best way to understand a chain is to index it. So I pointed my existing EVM tooling at Tempo’s RPC, wrote a custom CDC pipeline for the parts that broke, and built a dashboard on top. The whole thing from CDC worker, API, to real-time frontend took less than a week. Eight million blocks later, I have some opinions.

A note on how this was built: I leaned heavily on LLMs throughout as a force multiplier, architecture discussions, debugging ClickHouse type mismatches at 2am, drafting schemas, iterating on pipeline design. The workflow was human-driven and agentic: I brought the blockchain engineering knowledge and system design instincts, the LLM brought speed. Every architectural decision, every debugging session, every “wait, this data shape is wrong” moment was mine but I got there 5x faster than I would have alone. This is what building looks like now.

The result is live at sandglasses.xyz. This post is about what broke, what I built, and what the data revealed.

One caveat upfront: Tempo is still on testnet. The absolute numbers, volume, transaction counts, fill rates are testnet numbers, not production metrics. What’s interesting isn’t the scale but the patterns: how the architecture behaves, what the data shape looks like, and what primitives are actually being used.

The first thing that broke: transaction decoding

The event layer was easy. Tempo exposes 35 event signatures across 10 precompiles, TIP-20 tokens, a stablecoin DEX, a fee manager, payment streams, a keychain for session keys and they all emit standard EVM logs. I wrote a rindexer YAML config with topic-only filters, pointed it at ClickHouse, and had raw event data flowing within an hour. Standard EVM indexing, nothing surprising.

Then I tried to understand the transactions themselves.

Tempo’s native transaction type is 0x76, an account abstraction envelope that looks nothing like any EIP-2718 type I’ve worked with. Where a normal EVM transaction has a single “to” and “data” field, a 0x76 transaction carries a calls array (batched operations), two separate signatures (user and optional fee payer), 2D nonces, and an optional feeToken field for paying gas in stablecoins.

Here’s what one looks like from the RPC:

    {
      "type": "0x76",
      "calls": [
        {"to": "0x20c0...", "value": "0x0", "input": "0x095ea7b3..."},
        {"to": "0xDEc0...", "value": "0x0", "input": "0xa694fc3a..."}
      ],
      "nonceKey": "0x0",
      "nonce": "0x7",
      "feeToken": null,
      "feePayerSignature": null,
      "from": "0xa10d...",
      "signature": {
        "type": "secp256k1",
        "r": "0x...", "s": "0x...", "yParity": "0x1"
      }
    }

My first instinct was to decode the raw RLP bytes, as you would for any custom transaction type. I spent some time trying to make alloy’s Decodable trait work on the 0x76 wire format before realizing the shortcut: Tempo’s eth_getBlockByNumber returns these transactions fully deserialized as JSON. The RPC does the decoding for you. No raw byte parsing needed — just serde structs.

The decision then was whether to use reqwest + hand-rolled serde types, or the tempo-alloy crate that extends alloy’s type system with native Tempo support. I went with tempo-alloy. It plugs into alloy’s provider system so I get typed access to the full envelope:

    match rpc_tx.inner.inner() {
        TempoTxEnvelope::AA(aa_signed) => {
            let tx = aa_signed.tx();
            let fee_token = tx.fee_token.map(|a| format!("{a:#x}"));
            let fee_payer = tx.recover_fee_payer(from).unwrap_or(from);
            for (i, call) in tx.calls.iter().enumerate() {
                // each call becomes its own row
            }
        }
        envelope => { /* legacy/EIP-1559/EIP-2930 */ }
    }

Proper signature recovery matters here. When a transaction is sponsored, the fee payer is a different address than the sender, and you need to recover it from a separate signature field. tempo-alloy handles that. The cost is coupling to their release cadence, but for a chain-specific indexer that trade-off is fine.

Building the CDC pipeline

With events handled by rindexer and transaction decoding sorted, I needed to bridge the gap: poll blocks, decode the Tempo-specific fields that rindexer can’t see, and write structured data to ClickHouse.

The architecture is a straightforward CDC (Change Data Capture) pattern. A single Rust binary runs a poll loop: read the cursor, fetch blocks from the RPC in parallel batches, decode, write to ClickHouse, advance the cursor.

The key design choice was flattening batched transactions. Each call inside a 0x76 transaction gets its own row in ClickHouse. A single transaction with three calls produces three rows, each linking back to the parent tx_hash via a call_index. This makes it trivial to query “show me all calls to the DEX contract” without parsing nested JSON. The flattening costs some storage but makes every downstream query simpler.

The block cursor lives in ClickHouse itself, a ReplacingMergeTree table that the worker updates after each batch. On startup, it checks the cursor first, falls back to max(block_number) from the blocks table, then defaults to block 0 (backfill) or chain tip (live mode). Three-tier resolution means I can blow away the cursor table without losing progress.

Fetching happens in parallel with bounded concurrency, 10 concurrent RPC calls per batch, each getting a block plus its receipts. Results are sorted by block number and processed in order, stopping at the first gap. If block 1005 fails but 1004 and 1006 succeed, I write up to 1004 and retry from there. ReplacingMergeTree makes partial writes safe, duplicates get deduplicated at merge time.

The satisfying moment was watching the worker catch up from block 0 across 8.4 million blocks. Batch logs ticking over, the “behind” count dropping, then settling into a steady poll rhythm at 200ms intervals against 500ms block times.

The token discovery puzzle

This one was my favorite problem. TIP-20 tokens on Tempo are precompiles at 0x20C0… addresses; they have no deployment bytecode and no creation transaction. You can’t watch for contract deployments to discover them.

First attempt: hardcode the known tokens. Works for a demo. Breaks the moment someone creates a new token.

Second attempt: the TIP20Factory precompile emits TokenCreated events, which rindexer already indexes into ClickHouse. Query that table, get token addresses with names and symbols. This covers every factory-created token.

Third: I noticed tokens appearing in RebalanceSwap and OrderPlaced events that had no corresponding TokenCreated entry. Some tokens predate the factory, or were created through a different path. So I wrote a discovery query that scans all the rindexer event tables for token addresses not yet in the map.

Fourth: for every unknown address, make raw eth_call requests with the symbol() and name() selectors, decode the ABI-encoded string response, and persist the result back to ClickHouse. This way I never hit the RPC for the same token twice across restarts.

The runtime keeps an in-memory HashMap behind an RwLock, refreshed every 60 seconds. The three-layer resolution: factory events, persisted RPC-resolved metadata, live RPC fallback, handles every token I’ve seen so far without a single hardcoded address.

I should have built this before hardcoding anything. The three-layer approach is simple enough that it could have been the first implementation, and I would have avoided the “why is this token showing as 0x20C0…” phase entirely.

The dual gas lane surprise

When I first visualized gas utilization, I showed a single percentage. It was meaningless.

Tempo blocks have four gas fields: general_gas_limit, shared_gas_limit, general_gas_used, and payment_gas_used. The general lane handles computation-heavy transactions (DEX orders, contract calls). The payment lane handles stablecoin transfers. Each has its own limit, with shared overflow capacity between them.

A single “38.7% gas utilization” number hides the entire story. The payment lane carries disproportionate value relative to gas consumed; stablecoin transfers are cheap in gas terms but represent the bulk of economic activity. To show the real picture, I had to split the computation per lane.

This is the kind of insight you only get by building the visualization yourself. The raw data was correct from the start, the story it told depended entirely on how you rendered it.

What the data told me

After indexing 8.4 million blocks of testnet data, here’s what I actually learned about Tempo. The numbers are testnet-scale, what matters is the patterns, not the absolutes.

**Fee sponsorship is real and heavily used — even on testnet.** Over 200,000 transactions have a fee payer that’s different from the sender. On a testnet. This isn’t a theoretical feature, someone is actively building sponsorship infrastructure. The keychain precompile (session keys with spending limits) enables this without custody risk — the sponsor authorizes a key with constraints, not a blank check. The indexer caught this by recovering both signatures from every 0x76 transaction and comparing them.

**The Fee AMM is a genuinely novel primitive.** Instead of EIP-1559’s base fee mechanism, Tempo prices gas conversion through an AMM. When you pay fees in a stablecoin, the conversion rate is determined by a liquidity pool, not a protocol formula. I’m seeing roughly 1,000 Fee AMM swaps per day, enough activity to maintain price discovery, not enough to suggest gaming. Whether this produces more stable or more volatile gas pricing than EIP-1559 is the question I’ll be watching.

**500ms block times, no reorgs.** Block times are deterministic, which makes the CDC pipeline dramatically simpler; no confirmation depth, no reorg handling, no orphan blocks. For an indexer builder, this is luxury. On Ethereum or Polygon, I’d need at least 12-block confirmation depth and a reorg reconciliation layer. On Tempo, I write data the moment I see a block and never look back.

**Stablecoin volume will be the real economic indicator.** On a chain with no gas token, market cap and TVL are the wrong metrics. What matters is payment flow. The testnet volume is obviously not meaningful in dollar terms, but the infrastructure is already there and the dual gas lane design ensures that payment activity can never be crowded out by DEX speculation, which is a guarantee no other chain makes at the protocol level.

**DEX fill rate patterns are worth watching.** The on-chain CLOB shows roughly 19K orders per day with a 27% fill rate on testnet. The absolute numbers will change on mainnet, but the ratio is interesting; most orders don’t fill, which is what you’d expect from a functioning limit order book with real spread dynamics rather than wash trading (which produces fill rates near 100%).

What I’d do differently

I should have started with reqwest + serde structs for the initial prototype instead of immediately reaching for tempo-alloy. The alloy integration is the right long-term choice, but it added friction during the exploration phase when I was still figuring out what the data looked like. Prototype with the simplest tool, migrate once you know the shape.

One thing I got right from day one: the WebSocket fan-out architecture. Broadcast channels per topic (swaps, transfers, fees, lanes, sponsors, streams) with a registry that routes webhook events to the right channel. Clients subscribe to what they care about, get snapshot replay on connect, and backpressure is handled per-channel. This pattern scaled cleanly from one dashboard client to many without touching any query logic.

Try it

The dashboard is live at sandglasses.xyz real-time analytics on a payment-native chain.

If you’re curious about what this architecture looks like from the inside (dual gas lanes, sponsored transactions, an on-chain CLOB for stablecoins, gas priced through an AMM) the data is there. Point your own tools at Tempo’s RPC and see what you find.

Building this changed how I think about chain design. Most chains optimize for DeFi composability. Tempo optimized for payments, and then built DeFi on top of a payments-first architecture. The data suggests that’s a more interesting trade-off than it sounds.

✨ This quick article is here for you to build your Cairo skills. We will cover different subjects through a simple project: Build your first ERC20 token and deploy a custom Faucet 💧 linked to this token. This will strongly increase your knowledge of Cairo and give you a first idea of what you can simply achieve with Cairo !

A faucet is a service that provides tests tokens to users, generally on a Testnet network. While these tokens have no ‘real world’ value, they enable users to experiment with Blockchain features, without having to spend real money on the mainnet.

First of all, I’ll summarize the Tech tools we will manipulate through this cool project :

1. Timestamp manipulation on Cairo
2. Cairo Logic
3. ERC20 Standard: we will implement a simple ERC20 token
4. Testnet deployment script using Starknet.py

Project Setup

If you’re new to Cairo, I am providing some simple command lines to get you a dedicated Coding environment for StarkNet :

A — Creating our Faucet 💧

Let’s create a new Cairo contract under contracts/SimpleFaucet.cairo and add the declaration and imports on the first lines :

// contracts/SimpleFaucet.cairo

%lang starknet

from starkware.cairo.common.cairo_builtins import HashBuiltin
from starkware.cairo.common.math_cmp import is_le
from starkware.cairo.common.bool import TRUE, FALSE
from starkware.cairo.common.uint256 import Uint256
from starkware.starknet.common.syscalls import get_caller_address, get_block_timestamp
from openzeppelin.access.ownable.library import Ownable

from openzeppelin.token.erc20.IERC20 import IERC20

This SmartContract has the purpose of allowing anyone to mint new tokens given a specific ERC20 token.

First of all, let’s think about what we need as Storage for our faucet :

• The ERC20 token address we want to Faucet on
• The amount of token a user is allowed to mint per transaction
• The limitation time between each mint
• User’s next unlock time, will map user’s wallet to his next allowed faucet time. Works the same as a map in Solidity

We will therefore use the @storage_var possibility of Cairo for that. Let’s see this in practice :

//
// Storage
//

# ERC20 token address
@storage_var
func token_address() -> (address : felt){
}

# Allowed Amount per mint
@storage_var
func allowed_amount() -> (withdraw_value : Uint256){
}

# Timedelta between each mint
@storage_var
func waiter() -> (wait_time : felt){
}

# Next unlock time per user
@storage_var
func user_unlock_time(address : felt) -> (unlock_time : felt){
}

Nice ! You can still compile at this time using nile to check you are not doing anything wrong -> nile compile contracts/SimpleFaucet.cairo

To initialize a Contract, we also need a constructor, which will provide the initial state of the SmartContract. The constructor here needs several attributes :

• owner : The owner address that can manage the SmartContract
• _token_address : the ERC20 address we will create later on
• _allowed_amount : the amount of token allowed per mint
• _time : UNIX time we want to set between each mint

@constructor
func constructor{
        syscall_ptr : felt*, 
        pedersen_ptr : HashBuiltin*, 
        range_check_ptr
    }(
    owner : felt, 
    _token_address : felt, 
    _allowed_amount : Uint256, 
    _time : felt
){
    Ownable.initializer(owner);
    token_address.write(_token_address);
    allowed_amount.write(_allowed_amount);
    waiter.write(_time);
    return ();
}

Our contract has now its constructor ! Great job.

Let’s go into more detail now and implement the core functions. The main utility of a faucet will be to check whether a user is allowed to mint or not. We therefore need to create this dedicated function that will read our user_unlock_time variable and check if it’s unlock_time has past the current block timestamp : user_unlock_time <= timestamp. We’ve imported such a utility at the beginning of this file!

• get_block_timestamp()

@view
func isAllowedForTransaction{
        syscall_ptr : felt*, 
        pedersen_ptr : HashBuiltin*, 
        range_check_ptr
    }(address : felt) -> (success : felt){
    alloc_locals;
    let (unlock_time : felt) = user_unlock_time.read(address);
    if (unlock_time == 0){
        return (TRUE,);
    }
    let (timestamp : felt) = get_block_timestamp();
    let (unlock_time : felt) = user_unlock_time.read(address);
    let (_is_valid : felt) = is_le(unlock_time, timestamp);
    if (_is_valid == TRUE){
        return (TRUE,);
    }
    return (FALSE,);
}

Tada ! We are fancy and adding a @view decorator here in order to be able to use it through the ABI later on for example !

This is now our final step for this simple faucet SmartContract, you’re almost there ! Indeed, we now need an external function that can also be used through the ABI in order for a user to mint their tokens. For sure we will use the previously created function and deal with the ERC20 token.
We will go through an important concept of Cairo : Interface manipulation.

To put it in simple words, we’re going to manipulate a “ghost” contract that only have declared functions, and is morphing its behavior given a ERC20 token address (that’s why we needed the storage var !)

For that, we imported the OpenZeppelin Interface for an ERC20 contract : IERC20

@external
func faucet_mint{
        syscall_ptr : felt*, 
        pedersen_ptr : HashBuiltin*, 
        range_check_ptr
    }() -> (success : felt){
    alloc_locals;

    let (caller_address : felt) = get_caller_address();
    let (_allowed_amount : Uint256) = allowed_amount.read();
    let (_is_allowed : felt) =
isAllowedForTransaction(caller_address);
    if (_is_allowed == TRUE){
        let (timestamp : felt) = get_block_timestamp();
        let (_time_to_wait : felt) = waiter.read();
        user_unlock_time.write(caller_address, timestamp + _time_to_wait);
        let (token : felt) = token_address.read();
        let (success : felt) = IERC20.transfer(
contract_address=token, recipient=caller_address, amount=_allowed_amount
);
        with_attr error_message("Faucet Mint Failed"){
            assert success = TRUE;
        }
        return (TRUE,);
    }
    return (FALSE,);
}

Let’s notice the Interface utilization : the IERC20 Interface, as any interface, will always take the contract_address argument to morph the used function to this address, and finally, we pass arguments as usual.

Magnificent, we manage to finish our Faucet Contract, and he’s now ready to be deployed. First of all, ensure it’s compiling using nile compile contracts/SimpleFaucet.cairo

B —Simple ERC20 Token

Building an ERC20 is quite a fast task if we don’t want to focus on specific use cases. Let’s use a simple ERC20 implementation that uses basic functions from the standard :

cairo-timestamp-scheduler/SimpleERC20.cairo at main · ExoMonk/cairo-timestamp-scheduler

Don’t forget to compile !

C— Deployment

This is the final stage of the project. You have done really cool stuff here ! Now it’s time to go live on the Testnet ! ✨

There’s plenty of tools on the StarkNet ecosystem to deploy contract, today we’ll use Starknet.py one with Python !

pip install starknet.py

Here is our Deployment Script : (Make sure you update to your needs, especially the OWNER constant that must be one of your wallet addresses (ArgentX/Braavos)

Once you’re ready to deploy, run python scripts/deploy.py

You’ve been able to deploy both Contracts to the TestNet and they’re ready to be used ! Bravo

Head to Voyager Testnet website and check your contracts ! You’lle be able to easily interact with them using readContract and writeContract page.

1. Step 1 : Fund the Faucet by transferring tokens from your wallet to the Faucet using the transfer functions
2. Step 2 : Use the Faucet contract to mint your tokens from a different wallet !

And voilà !

Thanks for reading, I hope you’ve been able to reproduce it easily and learned about Interface, ERC20, Timestamp and Faucet on Cairo !

I am providing you with the complete GitHub repository right here :

GitHub - ExoMonk/cairo-timestamp-scheduler: Cairo StarkNet : Limit user's actions by time

Thanks for reading,

Exo

https://twitter.com/0xExoMonk

Sir, What’s Abstraction ?

The abstraction process is the practice of hiding information. This increases the ability of a computer system to be used at a higher level with less knowledge of the processes going on underneath.

In a programmer PoV, let’s say he hides all but the relevant data about an object in order to reduce complexity and increase efficiency.

Account Abstraction definition

On the Ethereum network there are currently two types of accounts.

• EOA : External Owned Accounts are wallets from which cryptocurrency is transacted in send and receive functions that exist outside of the EVM (Ethereum Virtual Machine) : Cold Wallets as Ledger, MetaMask, Phantom, …

• Contract accounts are “Smart Contracts” that exist in the EVM. For example pools on Uniswap are basically Smart Contracts.

Ethereum account abstraction has the goal of reducing from two account types down to one, a Contract Account. The single account type will have the functionality to transact both tokens and contract. Developer and user will no longer need to make a distinction between account type since transacting will be moved fully into the EVM and off of the blockchain protocol.

External Owned Account precision

EOAs have three properties:

• A balance to represent the amount of ETH available to the account
• A nonce to ensure that every transaction is unique
• An address to uniquely identify the account on the network

It’s important to mention that on Ethereum, every transaction must be initiated from an EOA. That means that when a transaction is executed by the Ethereum Virtual Machine (EVM) , the first account being touched must be an EOA and the corresponding account must pay a fee to the miner for the execution of the entire transaction.

Every account on Ethereum is associated with a cryptographic object called the Keypair :

• Private Key : used to sign digital messages
• Public Key : allows anyone to verify that a given signature was signed by its corresponding private key

Account Abstraction on StarkNet and ZkSync

As of today, StarkNet and ZkSync 2.0 are the most advanced in terms of Account Abstraction and they both manage to implement it in a way.

AA holds two main goals :

• Signature abstraction: allow different account contracts to use different signature validation schemes.
• Payment abstraction : Allow different models of payment for transactions. For example, payment by another party/contract or pay in another token than ETH

The model of StarkNet Account are still represented by contracts, so-called “account contracts”. To put it in simple word : Any Cairo Smart Contract deployed on StarkNet can be an Account, the only requirement is that they comply with a specific interface with methods to validate and execute transactions.

On ZkSync side, an account has also 2 functions to implement : validateTransaction & isValidSignature

With this abstraction, we directly see opportunity :

• Using Multiple keypairs to validate a transaction (simply put multi-sig all-in-one)
• Changing the Keypair of you Account (like rotating keys)
• Using a different signing scheme than ECDSA

What could it bring ?

This could be the most important part of this story : let’s go more deeply on the use cases of Account Abstraction. We can split these use case in two different domain :

• User Simplification
• Technical Use Cases

User Simplification : Session Keys

Let’s say you are playing an On-Chain game : currently you need to sign every single transaction by your own. It means each time you have to make an action, you need to sign a transaction :

Collect rewards, move your character, send a message, …

Session Key is basically the idea to authorized to play games for a certain period of time. We generated a session key held in the browser’s local storage and only authorized to sign transactions for 10 minutes. After these 10 minutes, the key will be revoked and you will need to create a new one and authorize it again.

In that extend, you can also imagine creating batch transactions : the same abstraction as you would be in a Supermarket, choosing product, and paying only one time at the end.

User Simplification : Transaction automation and splitting rights

With Abstracted Account, you could implement a function which changes the main signing key of a given wallet, or even manage multiple signing keys. You could have your admin key in a cold wallet and other keys held on less secure devices and only authorized to perform certain actions.

A cool example :

My most secured key, that I don’t use much, would be the only key that can transfer or send more than 1k$ to another Account, however, I can also have those less secure key on my computer to perform actions such as claiming rewards on some specific decided dApps (AAVE, …) or another one to perform any transaction on an On Chain game.

Now let’s say those key are held in a server that performs automated transactions / running your own bot : you can ensure that these key can only be used to perform actions you decided and improve security.

One last utility could be a protocol built that DCA on your behalf certains token as a recurring transaction.

Technical Use Case : Paying fees for someone else

This is one of the most interesting thing you can do with Account Abstraction. basically imagine that an account can pay the fees of another account, how genuine is that ? I can only imagine how powerful it could be for a protocol to onboard their users by paying their fees.

Final thoughts

We have seen how Account Abstraction can be a game changer in blockchain future. I am personally deeply convinced that a new era of use cases will come with Abstracted account, especially regarding the video game industry on-chain. I hope you understood everything about Account Abstraction, and that I gave you some reflexion area around the subject !

Later I will propose you a story on how you can customize a Cairo Account Smart Contract on StarkNet and build a real use-case together.

@ExoMonk

Ressources

• https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/account-abstraction/ — Account Abstraction, EthHub
• https://www.argent.xyz/blog/wtf-is-account-abstraction/
• https://github.com/argentlabs/argent-contracts-starknet — Cairo ArgentX Account implementation
• https://github.com/sambarnes/cairo-multisig — Cairo MultiSig Account Contract
• https://matterlabs.medium.com/introducing-account-abstraction-l2-l1-messaging-and-more-760282cb31a7 — ZkSync2.0 Account Abstraction

If you are not familiar with StarkNet, a recent Zk-Rollup, you may read this presentation before : StarkNet Overview

Cairo is one of the most interesting languages I’ve used, It is a language that includes a simple syntax that is a beautiful mix between Python & Rust. Cairo is in fact the Smart Contract Langage for StarkNet. However, beyond its syntax, the language embeds much more complex notions, memory optimisation and allocation with pointers & syscalls, powerful computation on chain, and so much more. You could even imagine building a Neural Network in Cairo, compile it and execute it on chain !

✨ It feels like a polyvalent langage right ?

It’s been now few months I have been involved into facing the Cairo learning curve. This read will overtake my Cairo developer point of view to accelerate your path for starting your StarkNet Journey.

Your developer environment

Let’s start with the basics : this will be assuming you are a first time Cairo user, and we will go through the process to easily setup your development environment.

First of all, you’ll need to get you either a Mac or Linux distribution. If you are on Windows, I suggest creating you a dedicated Docker environment where you’ll be able to setup.

Let’s deep dive onto the dependencies first : make sure you have python3 installed & virtualenv ready and then run :

sudo apt install -y libgmp3-dev  

On mac :

CFLAGS=-I`brew --prefix gmp`/include LDFLAGS=-L`brew --prefix gmp`/lib pip install ecdsa fastecdsa sympy

Now you are ready to create your first project. We will be creating our working folder project : starknet-project and configure Starknet & Cairo :

mkdir starknet-project 
cd starknet-project
python3 -m venv cairo-env 
source cairo-env/bin/activate 
pip install cairo-nile 
pip install openzeppelin-cairo-contracts
nile install 

...

✨  Cairo successfully installed!

Good job ! Cairo is now installed on your environment and is ready to be used. We have been installing a simplifier tool called “nile” in order to ease our development process : https://github.com/OpenZeppelin/nile

Nile is basically a python development environment for developing StarkNet contracts, for additionnal resource, you can find a summary of mine Right Here !

We have also installed the OpenZeppelin python library to import Cairo Smart Contract template : Cairo-Contracts.

Our projects is now fully setup and will be composed of 3 folders :

• contracts: Folder containing our .cairo Smart Contract
• tests: Our testing folder to run while developping those Smart Contracts
• artifacts: Folder that will be created once we will be compiling our Smart Contracts.

Testing our Installation

To test our installation we are going to compile a Starknet Account Smart Contract and deploying it using Nile, and then StarknetJS

Create a file under the contracts folder name ArgentAccount.cairo with this content :

# contracts/OZAccount.cairo  

%lang starknet  

from openzeppelin.account.Account import constructor

This will simply use the OpenZeppelin template to deploy our Account Smart Contract.

Let’s deploy our Account on the Goerli network of Starknet, using our nile tool !

nile compile contracts/OZAccount.cairo --account_contract

...

🔨 Compiling contracts/OZAccount.cairo
✅ Done

The Smart Contract is now compiled under the artifacts folder and is ready to be deployed. We now have two schools : using CLI (nile way), or using a web3 intergation framework, that would act as EthersJS or Web3JS : Starknet.JS

Using Nile

The Account constructor takes one argument : a Hex address you are going to pass to the nile deploy commande. You can easily generate a random one on the internet (For example here)

As you may have seen in the nile commande, we are going to use the deploy one :

nile deploy OZAccount <YOUR_GENERATED_ETH_ADDRESS> --alias OzAcc --network goerli

...

🚀 Deploying OZAccount
⏳ ️Deployment of OZAccount successfully sent at XXX
🧾 Transaction hash: XXX
📦 Registering deployment as OzAcc in goerli.deployments.txt

Using StarknetJS

We need to install starknet js using the following :

npm install -g yarn
yarn init 
yarn add starknet@next 
touch index.js

and add to package.json, the line :

"type": "module"

Let’s build our file index.js now :

import fs from "fs";
import {
    Contract,
    defaultProvider,
    ec,
    json,
    stark,
} from "starknet";

console.log("Reading Argent Account Contract...");
const compiledArgentAccount = json.parse(
    fs.readFileSync("./artifacts/OZAccount.json").toString("ascii")
);

// Generate public and private key pair.
const privateKey = stark.randomAddress();
const starkKeyPair = ec.genKeyPair(privateKey);
const starkKeyPub = ec.getStarkKey(starkKeyPair);

// Deploy the Account contract and wait for it to be verified on StarkNet.
console.log("Deployment Tx - Account Contract to StarkNet...");

const accountResponse = await defaultProvider.deployContract({
    contract: compiledArgentAccount,
    constructorCalldata: [starkKeyPub],
    addressSalt: starkKeyPub,
});

// Wait for the deployment transaction to be accepted on StarkNet
console.log("Waiting for Tx "+ accountResponse.transaction_hash +" to be Accepted on Starknet - Argent Account Deployment...")
await defaultProvider.waitForTransaction(accountResponse.transaction_hash);

console.log("✨ Account Deployed at "+ starkKeyPub +" !!")
console.log(accountResponse.address)

//Ready to be used !!!
const accountContract = new Contract(
    compiledArgentAccount.abi,
    accountResponse.address
);

This file is pretty simple to understand :

• Part 1 : Reading our Compiling Smart Contracts with starknetJS
• Part 2 : Generating a random Private and Public key
• Part 3 : Deploy our Contract
• Part 4 : Our contract is now deployed and ready to be used for further manipulations !

We can now run and deploy our Account :

node index.js

...

Reading Argent Account Contract...
Deployment Tx - Account Contract to StarkNet...
Waiting for Tx XXX
to be Accepted on Starknet - Argent Account Deployment...
✨ Account Deployed at XXX !!

Perfect ! You are now fully operational for starting your Cairo Journey.
To finish with, I can only encourage you learning this langage, and we have such amazing resource I am sharing with you : some must have for your pathing on your Cairo Learning Curve.

Ressources

https://github.com/l-henri/starknet-erc20 — Build your own ICO in Cairo

https://bit.ly/3zgsde3 — Nile + StarknetJS Tutorial

https://bit.ly/3xhBem2 — Nile Cheat Sheet

https://t.co/hiOqeA7Yix — Starknet interactive tutorial

When building Web3 applications, our ultimate goal is to deploy our Smart Contract on the mainnet of EVM-enabled blockchains (Ethereum, Layer2, …) where it can be used by the everyone. But smart contracts are immutable and deploying on the mainnet is expensive. We don’t want to deploy on the mainnet until our code is tested and our data structures are finalized. While our dApp is in development, we want to be able to experiment and evolve our data structures and simulate transactions using test accounts.

In this post, I will cover :

• Global Setup
• Project Setup
• Smart Contract deployment configuration and tests
• Introduction on how to configure a ReactJS Web3 dApp

Backbone of your setup

At first, you need the backbone of a specific setup configuration for a project. Most of them will be using a specific node and npm configuration and packages. Therefore we will need to check that we have all the card in our hands to handle it.

Downloading and installing Node.js and npm | npm Docs

node -v
v16.14.0
npm -v
8.3.1

Once you’re sure about your NodeJS installation, we will need to install 2 main packages for all of our projects : yarn & npx.

npm install -g npx 
npm install -g yarn 
mkdir template_project
cd template_project

Installing hardhat and web3 packages

Harhdat

Hardhat is a “task runner for Ethereum smart contract developers”. In practice, Hardhat helps you bootstrap your Solidity project with a template and give you all the scaffolding needed to test out your smart contracts and ultimately deploy onto an EVM-enabled Blockchain.

Some of you may know Truffle instead, it was standard procedure to use Truffle’s init, compile, test, and migrate features to bootstrap your Solidity projects. Some killer features Hardhat touts are stack traces when your Solidity contracts revert and logging system ! I can only encourage you to try it out.

Waffle

Hardhat is to be used with Ethereum Waffle, a lightweight test runner for Ethereum smart contracts. It has some really nice testing utils built in like Chai matchers for Ethereum addresses, hashes, and BigNumbers, it’s Typescript native, and plays really nicely with EthersJS.

Ethers

Ethers.js si the SDK for interacting with the Ethereum blockchain. Also really similar to web3JS, yet it is really easy to get set up. I ask anyone who is used to working with Web3.js to give Ethers a try.

yarn add --dev hardhat 
yarn add dotenv ethers @nomiclabs/hardhat-waffle ethereum-waffle chai @nomiclabs/hardhat-ethers

Project Configuration

We will start the last part of our setup : configure precisely your project and use testnet to check your project’s health.

Hardhat is here to help you, let’s run our first command:

npx hardhat

888    888                      888 888               888
888    888                      888 888               888
888    888                      888 888               888
8888888888  8888b.  888d888 .d88888 88888b.   8888b.  888888
888    888     "88b 888P"  d88" 888 888 "88b     "88b 888
888    888 .d888888 888    888  888 888  888 .d888888 888
888    888 888  888 888    Y88b 888 888  888 888  888 Y88b.
888    888 "Y888888 888     "Y88888 888  888 "Y888888  "Y888

Welcome to Hardhat v2.9.3

? What do you want to do? ...
> Create a basic sample project
  Create an advanced sample project
  Create an advanced sample project that uses TypeScript
  Create an empty hardhat.config.js
  Quit

√ What do you want to do? · Create a basic sample project

This will install a few more dependencies for development and testing. You should now see a few more files and folders in your project:

• test: This folder contains a test script written in Chai and it is used to test our smart contract
• hardhat.config.js: This file contains the configuration for Hardhat
• scripts: This folder contains a sample script to show to deploy a smart contract
• contracts: This is the folder, which includes the files, in which we write our smart contract code.

An object is exported from hardhat.config.js to set up your project. This object can have entities like defaultNetwork, networks, solidity, paths and mocha.

In order to ease your move between local, testnet and mainnet, we added the dotenv package, in order to set environment variable through a .env file :

touch .env
//Windows
echo > .env

and add your testnet / mainnet private key and RPC :

RINKEBY_ALCHEMY_API_KEY = ""

GOERLI_ALCHEMY_API_KEY = ""

MAINNET_ALCHEMY_API_KEY = ""

PRIVATE_KEY = ""

Network Configuration:

There are two kinds of networks in Hardhat: JSON-RPC based networks, and built-in Hardhat Network.

The default network is “hardhat” but you can customize which network to be used as default while running Hardhat by setting defaultNetwork field on your hardhat.config.js file. It will somehow look something like this :

require("@nomiclabs/hardhat-waffle");
require("dotenv").config();

module.exports = {
    defaultNetwork: "hardhat",
    networks: {
        hardhat: {},
        rinkeby: {
            url: "https://eth-rinkeby.alchemyapi.io/v2/"+process.env.RINKEBY_ALCHEMY_API_KEY,
            accounts: [process.env.PRIVATE_KEY]
        },
        goerli: {
            url: "https://eth-rinkeby.alchemyapi.io/v2/"+process.env.RINKEBY_ALCHEMY_API_KEY,
            accounts: [process.env.PRIVATE_KEY]
        },
    },
    solidity: {
        version: "0.8.7",
        settings: {
            optimizer: {
                enabled: true,
                runs: 200
            }
       }
    },
    paths: {
        sources: "./contracts",
        tests: "./test",
        cache: "./cache",
        artifacts: "./artifacts"
    },
    mocha: {
        timeout: 40000
    }
};

Hardhat command and testing

This is the last part before you can really start building on your project : Testing. You will need to become familiar with hardhat commands in order to be comfortable with testing, debugging and deploying Smart Contracts :

• npx hardhat node — Run the node task to start a JSON-RPC server on top of Hardhat Network (your local ethereum blockchain)
• npx hardhat test — To run tests stored in the test folder
• npx hardhat compile — To compile the entire project, building your smart contracts
• npx hardhat clean — To clean the cache and delete compiled smart contracts
• npx hardhat run —-network <network> script/path — To run a specific script in a specific network

For basic development on a local environment, you will need to run in a separate shell :

npx hardhat node

and

npx hardhat run scripts/sample-script.js
//If you want to run it on a testnet 
npx hardhat run --network rinkeby scripts/sample-script.js

And voilà !

Configure a web3 dApp

To finish with, I will show you how to quickly setup a web3 dApp given all you have been able to read.

Connect Metamask to localhost

Copy any private key from the account that was logged into your shell when you run the npx hardhat node command and import it to Metamask.

Web App to connect Metamask

1. Create a React.JS application

npm install -g create-react-app
mkdir template_dapp_project
cd template_dapp_project
npx create-react-app ./
rm README.md

2. Install dependencies and configure hardhat

yarn add --dev hardhat
yarn add dotenv ethers @nomiclabs/hardhat-waffle ethereum-waffle chai @nomiclabs/hardhat-ethers
npx hardhat

√ What do you want to do? · Create a basic sample project

Run your node (npx hardhat node) and deploy you contract :

npx hardhat run scripts/sample-script.js

3. Configure setup files

.env

RINKEBY_ALCHEMY_API_KEY = ""
GOERLI_ALCHEMY_API_KEY = ""
MAINNET_ALCHEMY_API_KEY = ""
PRIVATE_KEY = ""

hardhat.config.json

require("@nomiclabs/hardhat-waffle");
require("dotenv").config();

module.exports = {
    defaultNetwork: "hardhat",
    networks: {
        hardhat: {},
        rinkeby: {
            url: "https://eth-rinkeby.alchemyapi.io/v2/"+process.env.RINKEBY_ALCHEMY_API_KEY,
            accounts: [process.env.PRIVATE_KEY]
        },
        goerli: {
            url: "https://eth-rinkeby.alchemyapi.io/v2/"+process.env.RINKEBY_ALCHEMY_API_KEY,
            accounts: [process.env.PRIVATE_KEY]
        },
    },
    solidity: {
        version: "0.8.7",
        settings: {
            optimizer: {
                enabled: true,
                runs: 200
            }
       }
    },
    paths: {
        sources: "./contracts",
        tests: "./test",
        cache: "./cache",
        artifacts: "./src/artifacts"
    },
    mocha: {
        timeout: 40000
    }
};

3. Update your App.js file and run your app !

import React, { useEffect } from "react"; 
import Greeter from "./artifacts/contracts/Greeter.sol/Greeter.json"; 
import { ethers } from "ethers";   

function App() {   
  const connectWallet = async () => {     
    try {       
      const { ethereum } = window;        
      if (!ethereum) {         
        alert("Please install MetaMask!");         
        return;       
      }        
      const accounts = await ethereum.request({         
        method: "eth_requestAccounts",       
      });        
      console.log("Connected", accounts[0]);       
      fetchGreetings();     
    } catch (error) {console.log(error);}
  };    

  const fetchGreetings = async () => {     
    let contractAddress = "DEPLOYED_ADDRESS";     
    const { ethereum } = window;      
    if (!ethereum) {         
      alert("Please install MetaMask!");         
      return;       
    }        
    const provider = new ethers.providers.Web3Provider(ethereum);           
    const signer = provider.getSigner();     
    const contract = new ethers.Contract(       
      contractAddress,       
      Greeter.abi,       
      provider     
    );      
    const greeting = await contract.greet();     
    console.log(greeting);   
  };    

  useEffect(() => {     
    connectWallet();   
  }, []);    

  return <div></div>; 
}

export default App;

Run :

yarn start

You have now all the keys in your hands to start working on a clean environment !

https://twitter.com/0xExoMonk

The emergence of new blockchains & the technical improvements they bring are more and more felt. We see the interest of Layer 2 growing and their development accelerating because of the need to increase the scalability of solutions.

In the continuation of this reflection, I propose a complete analysis of the StarkNet environment, which brings many innovations in the possibilities that a Layer2 can offer.

The article will cover to begin with all the essential notions to understand the topics discussed (Zero Knowledge, ZkRollup, …). I think that anyone interested in cryptocurrencies and blockchain technology must assimilate this knowledge.

In a second time, I will present the parent company StarkWare which develops StarkNet/StarkEx through the solutions that are built and will be built. This article will be technical but at the same time affordable. This will be done through an introduction to the Smart Contract language of StarkNet: Cairo and its specificities compared to Solidity in particular, and some atypical and innovative subtleties.

To finish with, I shall share with you a small list of projects under construction & to be followed on the environment which will certainly play an important role in the explosion of the ecosystem.

Glossary :

• ZKP = Zero Knowlegde Proof
• ZKSTARK = Zero-Knowledge Scalable Transparent ARguments of Knowledge
• Rollup = Off-chain aggregation of transactions from a Smart Contract ETH
• ZK-Rollup = Rollup using ZKP
• Scalabilité = https://medium.com/starkware/redefining-scalability-5aa11ffc5880
• SHARP = Shared Prover

Zero Knowledge, ZKSTARK & Rollup

Let’s start with the basics of vocabulary, you will see that the terms may seem barbaric, but in the end they are as soft as cotton.

Zero Knowledge Proof

While blockchain has brought us great benefits such as transparency, immutability & decentralization, the notion of privacy is rarely discussed. This is where Zero Knowledge Proof (ZKP) comes in: a juicy mix of composability, privacy & immutability.

ZKP is an encryption scheme by which one party (the PROVIDER, which we will call PR) can prove the veracity of specific information to another party (the VERIFIER, which we will call VER) without disclosing any additional information.

In a concrete example, VER wants to collect a reward from a vault. In ZK, this gives:

• PR confidentially produces a key (K)
• VER verifies that the key (K) allows to obtain the reward
• The ZKP is verified, CQFD

In a same way, ZKP can also resolve:

• PR produces a key (K) and retrieves the reward from the vault confidentially
• VER verifies that the reward corresponds to a reward that is only available in this same vault
• The ZKP is verified, CQFD

In summary, the VER verifier will not know any information other than the boolean statement. The details of the other parties’ information and personal data remain anonymous.

As you can see, ZKP allows for privacy. But what is interesting with this method is that it is extremely simple, secure & allows an incredible scalability, it is chosen by many blockchain applications for these virtues.

Rollup & Zk-Rollup

An Ethereum Rollup is an off-chain aggregation of transactions within an ETH smart contract, which reduces fees and congestion by increasing throughput from its current 15 tps to over 1000 tps. It’s like having blockchains in the shadows that aggregate ETH blocks. (→ https://twitter.com/0xExoMonk/status/1486729691243298819)

ZK-Rollups are one of the options under development for building Layer 2 that increase scalability by processing mass transfers in a single transaction. Where Plasma creates one transaction per transfer, ZK-Rollups aggregate hundreds of transfers into a single transaction. The Smart Contract will deconstruct and verify all transfers held in a single transaction: another proof of scalability.

A ZKP approach is used to publicly present and record the validity of the block on the Ethereum blockchain. ZK reduces the computational and storage resources to validate the block by reducing the amount of data held in a transaction; no knowledge of the dataset is required.

ZKSNARK — ZKSTARK

I will introduce the last keys of this article: ZKSNARK & ZKSTARK, which are in fact two different types of Zero Knowledge proofs. A little background.

The ZK-Rollup scheme consists of two types of users: Relayers & Transactors.

1. Transactors create their transfer and broadcast the transfer over the network. The Smart Contract stores the data in two Merkle Trees (https://fr.wikipedia.org/wiki/Arbre_de_Merkle):

• The addresses in one Merkle Tree
• The transfers of the amounts in another one.

2. The Relayers collect a large amount of transfers to create an aggregate. It is the job of the relays to generate the SNARK proof: ZKSNARK

The SNARK proof is a hash that represents the delta of the blockchain state. The SNARK proof compares a snapshot of the blockchain before the transfers to another snapshot of the blockchain after the transfers and reports only changes in a provable hash to the main network.(https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/)

Prior to ZK-STARK, ZK-SNARK was used to create ZK proof systems, but required a trusted party or parties to initially configure the ZK proof system, which introduced the vulnerability of those trusted parties compromising the confidentiality of the entire system. ZK-STARK improves on this technology by removing the need for a trusted configuration.

As you can see, this new proof solves one of the biggest flaws of the old SNARK proof. This proof has been proposed by the StarkWare team in its Starknet environment that I will present later.

STARKs improve two of the problems of permissionless blockchains: scalability and privacy.

STARKs improve scalability by allowing developers to move computation and storage off-chain. Off-chain services will be able to generate STARK proofs attesting to the integrity of off-chain computations. These proofs are then delivered back to the chain for any interested party to validate the computation. Moving the bulk of the off-chain computation work using STARK allows the existing blockchain infrastructure to scale exponentially while confidently maintaining the integrity of the computations: it’s a game-changer asset.

Good! You now have all the keys in hand to enter the StarkWare: StarkNet ecosystem.

Starware x StarkNet

StarkNet is a decentralized, permissionless ZK-Rollup (ZKP-based) and uses ZKSTARK technology to scale exponentially without compromising privacy.

StarkNet Alpha was released on public testnet in June and on Mainnet in November of 2021. At the time of the Mainnet deployment, StarkNet was already providing general purpose computing in an Ethereum-like state.

Throughout development, the StarkWare team chose an approach that focused on releasing the most important features first, essentially sharing the evolution process with the community.

StarkNet is far from complete, but even now, developers can already create meaningful and complex applications. Today, there are hundreds of developers who rely on StarkNet, lot of dApps, and some external teams developing tools and infrastructure for the StarkNet ecosystem (which we will see in the last section).

A series of updates has provided many important features. Several caught my eye:

• L1 <-> L2 messaging,
• On-chain data and composability support
• Events support
• Basic pricing mechanism, Contract upgrade
• Wallet abstraction (which are now Smart Contracts)
• Testing framework, development tools, rapid confirmation

Since the beginning of the year, the ecosystem has reached its usability threshold: it is possible to build complete and amazing dApps. The team will now focus on the performance of the system: in its current state, it is capable of supporting a limited transaction flow. The goal is to achieve a TPS at least an order of magnitude higher than Ethereum’s by the beginning of the second half of 2022, at a cost at least two orders of magnitude lower than Ethereum’s.

StarkNet must be a fully decentralized permissionless network with mechanisms for leadership election and governance. Achieving this goal will become the primary objective once throughput skyrockets and costs drop.

StarkEx is the scaling engine for some of the most successful dApps using L2: dYdX(perpetual contracts), DeversiFi (trading and cash payments), and for Immutable X (IMX) and Sorare (NFT typing and trading) now.

Let’s talk about Fractal Scaling : Layer 3 & more

The exorbitant cost of transactions on Ethereum asymptomatically pushes L2s to meet those same costs. StarkWare’s paradigm is that, end users will conduct the majority of their business on L2s due to the dramatically reduced transaction costs, growing support for DeFi tools, and the increased liquidity provided by them. L2s increase scalability with reduced gas cost per transaction and improved transaction rates. At the same time, L2s retain the benefits of decentralization, general purpose logic and composability. However, some applications require specific customization that can be better served by a separate new layer: Let’s talk about Layer 3.

An L3 relates to an L2 as an L2 relates to an L1. L3s can be realized using validity proofs as long as the linked L2 is capable of supporting a Smart Contract Verifier (see Part 1). When L2s also use validity proofs submitted to an L1, as StarkNet does, it becomes a demented recursive structure where the compression benefit of L2 proofs is multiplied by the compression benefit of L3 proofs.

In other words, if each layer achieves, for example, a cost reduction of ratio 1000, the L3s in question can achieve a reduction of ratio 1M compared to the L1, while maintaining the same security. One could then imagine a transaction fee that would cost a fraction of the usual gas fee.

StarkWare explains the advantages of having a Layer 3:

• Hyper-scalability: taking advantage of the multiplicative effect of the recursive proof.
• Better control by the application designer of the technology stack:

More deterministic performance and cost
Customized data availability models (e.g., Validium-based or application-specific compression of chained data),

Faster functionality and technology speed (e.g., introducing new features that are not yet ready for general availability).

• Confidentiality: ZKP applied to privacy-preserving transactions on a public L2.
• Interoperability: independent L3s will interact via the L2, not the L1. L2 should obviously be cheaper than its L1.
• L3 as a “canary” network à la Kusama for Polkadot for the L2: new innovations can be tested on the L3 before being made available to the general public.

In the same way, we are kindly offered an example proposed by StarkWare to expose this theory of a Layer 3:

• A StarkNet with Validium data availability, for example, for general use by extremely price sensitive applications.
• Application-specific StarkNet systems customized for better application performance, for example, using designated storage structures or data availability compression.
• StarkEx systems (such as those serving dYdX, Sorare, Immutable, and DeversiFi) with Validium or Rollup data availability immediately bring combat-proven scalability benefits to StarkNet.
• Privacy StarkNet instances (in this example also as L4) to enable privacy-preserving transactions without including them in public StarkNets.

Fractal Scaling: From L2 to L3

Smart Contract on Starknet : Cairo

StarkNet is built on the Cairo programming language, the first production-level full von-Neumann Turing checker on Ethereum. It is in fact the language for Smart Contracts on the ecosystem. Cairo allows developers to use the power of ZKSTARK to create fully scalable applications. Let’s take a closer look.

Cairo : Smart Contracts

Cairo is a language for writing provable programs: the execution of a Cairo program produces a trace that can then be sent to a prover, which generates a STARK proof of the validity of the instruction or calculation represented by the Cairo program. The proof can then be checked with a verifier.

Today, most dApps are built around Smart Contracts Solidity implementing some kind of logic & interface, and a backend. These dApps, when successful, inevitably face the problem of scalability.

Increasingly, we see dApps solving their scalability problems by turning to evidence-based L2 scalable solutions (like DeversiFi with StarkEx). An off-chain component supports some of the more complex parts of the business logic and communicates with on-chain smart contracts, without giving up security, as all changes to the system state are certified by evidence (ZKP). Scalability improves because verifying an on-chain proof is exponentially cheaper than executing the business logic entirely on-chain.

With Cairo, the barriers to using proofs to achieve scalability are much lower: you write logic in Cairo, then the code has to be proven off-chain, and once that proof is validated on-chain, you end up with a dApp that can use the result with confidence — just as if it had run it on-chain.

Three points are expensive on Ethereum: computation, transmission and storage.

Cairo solves all three. To understand how it does this, we need to introduce a new concept — The Shared Prover (or SHARP).

The SHARP is the link between your Cairo code and your Smart Contract Solidity. It has three main components: a prover (off-chain), a smart contract verifier (on-chain) and a fact logger contract (on-chain).

The prover takes the execution trace of your program, proves that it is valid and sends this proof to the verifier. After verifying the proof, the on-chain verifier takes one more important step: it writes a fact attesting to the validity of the proof in the fact register. This fact is like a seal of approval without trust, certifying that the Cairo program was calculated correctly. Now all that is left for the dApp’s smart contract is to verify that this fact exists, in order to rely on the computation that was performed off-chain.

To go further into this development environment, I leave you with this notion :

https://seen-joke-82c.notion.site/StarkWare-Development-965f54711eb84dc79f3b61f22df9e383

Must Follow Projects on StarkNet

But now that you have understood everything about ZKP, StarkNet & Cairo, what to do?

StarkNet Wallet : ArgentX

The first step will be to configure your wallet. We will use ArgentX:

• download the chrome extension or check their repo

Unlike Ethereum L1 where private keys and accounts are generally the same thing (think EOA wallets), StarkNet supports account abstraction, meaning that each account is actually a Smart Contract that must be deployed before it can interact with the network. This is both a fantastic opportunity and an added complexity for a normal user.

The ArgentX wallet is used here to abstract away the complexity: it creates and secures private keys, deploys key-controlled account contracts, connects to decentralized applications and sends transactions to the StarkNet network.

Using a Smart Contract as a wallet is, in my opinion, a big step forward in security. ArgentX offers the same way to create Vaults as a wallet (thus automated multi-sig). All transactions with untrusted addresses are automatically blocked, unless you use guardians. This security covers all assets & transactions with trusted addresses are transparent

—

Currently, the available applications are mainly on the testnet of StarkNet, & to use them, you will have to get test tokens: https://faucet.goerli.starknet.io/

StarkNet Bridge

The 2nd most important thing to know: how to transfer funds from an L1 (Ethereum) to the L2 Starknet. The answer is in the StarGate bridge:

StarkGate Alpha

We will remain cautious though as this is again an Alpha, not yet audited.

StarkNet DEX — AMM

We shall start with what we are all looking for when entering a new ecosystem : DEX, Trading & AMMs.

As of today, several dApps stand out from the crowd:

• ZigZag Exchange : DEX

https://info.zigzag.exchange/

A decentralized exchange built around ZKP, with an OrderBook.

• ZKX: Perpetual Trading

https://twitter.com/zkxprotocol

• Starkswap: DEX AMM

https://medium.com/starkswap/the-starkswap-vision-6c73f8e66aab

A decentralized exchange with an Automated Market Maker

StarkNet Lending

• zkLend

https://linktr.ee/zkLend

zkLend is a money market protocol based on StarkNet. ZkLend offers a dual authorization suite of compliance-oriented solutions for institutional clients (“Apollo”) and an authorization-free service for DeFi retails users (“Artemis”).

StarkNet Launchpad

• Zkpad

ZkPad

As usual, in my opinion one of the focal points of a new ecosystem: the launchpad. The goal of the ZkPad gas pedal is to provide founders with strategic and operational support, including co-marketing on Twitter/Discord, partnership and ecosystem intros, access to a database of selected talent, including Cairo developers, UX/UI designers and marketers. The platform is specifically designed to open up investment opportunities, previously reserved for investment funds, to individuals.

StarkNet DeFi

• Magnety

https://twitter.com/magnetyfi

Magnety is an asset management protocol allowing anyone, such as investment groups, DAOs or individuals to create and manage a hedge fund via the Starknet & L1 DeFi ecosystem. The protocol allows you to create a highly customizable vault based on an investment strategy that you can choose. In my opinion a DeFi product to follow, highly secure thanks to ZKP.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

You will find a non-exhaustive list of projects under construction on StarkNet: https://starkware.notion.site/Projects-Building-on-StarkNet-a33dee55778a4515a9be9bdae02ee682

Follow More content :

https://twitter.com/0xExoMonk

L’émergence de nouvelles blockchains & l’amélioration techniques qu’elles apportent se font de plus en plus ressentir. On voit donc l’intérêt des Layer 2 s’agrandir et leur développement s’accélérer de part un besoin d’augmenter la scalabilité des solutions.

Dans la suite de cette réflexion, je vous propose une analyse complète de l’environnement StarkNet, qui apporte beaucoup d’innovations dans les possibilités que peut offrir une Layer2.

L’article couvrira pour commencer l’ensemble des notions essentielles pour comprendre les sujets abordés (Zero Knowledge, ZkRollup, …). Je pense que quiconque s’intéressant aux cryptomonnaies et tech blockchains se doit d’assimiler ces connaissances.

Dans un second temps, je présenterai la société mère StarkWare qui développe StarkNet/StarkEx à travers les solutions qui s’y construisent et construiront. Cet article sera technique mais à la fois abordable. Ceci se fera à travers une introduction au langage de Smart Contract de StarkNet : Cairo ainsi que ses spécificités par rapport à Solidity notamment, et quelques subtilités atypiques et innovantes.

Pour finir en beauté, je vous partage une petite liste des projets en construction & à suivre sur l’environnement qui certainement jouera un rôle important dans l’explosion de l’écosystème.

Lexique :

• ZKP = Zero Knowlegde Proof
• ZKSTARK = Zero-Knowledge Scalable Transparent ARguments of Knowledge
• Rollup = Aggrégation hors chain de transactions d’un Smart Contract ETH
• ZK-Rollup = Rollup qui utilise la ZKP
• Scalabilité = https://medium.com/starkware/redefining-scalability-5aa11ffc5880
• SHARP = Shared Prover

Zero Knowledge, ZKSTARK & Rollup

Posons les bases de vocabulaire pour commencer, vous le verrez les termes peuvent paraître barbares, mais finalement ils sont aussi doux que du coton.

Zero Knowledge Proof (ZKP)

Bien que la blockchain nous ait apporté de grands avantages tels que la transparence, l’immuabilité et la décentralisation, on aborde rarement la notion de confidentialité. C’est là qu’intervient la Zero Knowledge Proof (ZKP): un mélange juteux de composabilité, de confidentialité & d’immuabilité.

La ZKP est un schéma de chiffrement par lequel une partie (celle qui PROUVE que nous appellerons PR) peut certifier la véracité d’informations spécifiques à une autre partie (celle qui VERIFIE que nous appellerons VER) sans divulguer d’informations supplémentaires.

Sur un exemple concret, VER veut récupérer une récompense. En ZK, cela donne :

• PR produit de manière confidentielle une clé (K)
• VER vérifie que la clé K permet bien d’obtenir la récompense
• La ZKP est vérifiée, CQFD

De la même façon, la ZKP peut aussi se résoudre ainsi :

• PR produit une clé (K) et récupère la récompense du coffre de manière confidentielle
• VER vérifie que la récompense correspond bien à une récompense qui est uniquement disponible dans ce même coffre
• La ZKP est vérifiée, CQFD

Pour résumer, le vérificateur VER ne pourra connaître aucune information autre que la déclaration vraie ou fausse. Les détails des informations et des données personnelles des autres parties restent anonymes.

Vous l’aurez compris, le ZKP permet la confidentialité (privacy). Mais ce qui est intéressant avec cette méthode, c’est qu’elle est extrêmement simple, sécurisée & permet une scalabilité incroyable, elle est choisie par de nombreuses applications blockchains pour ces vertues. Le dernier en vue : Sorare, qui choisi de se tourner vers StarkNet comme solution de Scaling.

https://www.playtoearn.online/2021/05/19/sorare-embraces-zero-knowledge-proof-as-scaling-solution/

Rollup & Zk-Rollup

Un Rollup d’Ethereum est une agrégation hors chaîne de transactions au sein d’un smart contract ETH, qui réduit les fees et la congestion en augmentant le débit de ses 15 tps actuels à plus de 1000 tps. C’est comme si on avait des blockchains dans l’ombre qui agrègent les blocs d’ETH. (→ https://twitter.com/0xExoMonk/status/1486729691243298819)

Les ZK-Rollups sont l’une des options en cours de développement pour la construction de la couche 2 qui augmentent l’évolutivité grâce au traitement des transferts de masse en une seule transaction. Là où Plasma crée une transaction par transfert, ZK-Rollups regroupe des centaines de transferts en une seule transaction. Le Smart Contract déconstruira et vérifiera tous les transferts détenus en une seule transaction : encore une preuve de scalabilité.

Une approche ZKP est utilisée pour présenter et enregistrer publiquement la validité du bloc sur la blockchain Ethereum. ZK réduit les ressources de calcul et de stockage pour valider le bloc en réduisant la quantité de données détenues dans une transaction ; aucune connaissance de l’ensemble des données n’est nécessaire.

ZKSNARK — ZKSTARK

Je vais présenter les dernières clés de cet article : ZKSNARK & ZKSTARK, qui sont en fait deux différents types de preuves Zero Knowledge. Un peu de contexte.

Le schéma ZK-Rollup se compose de deux types d’utilisateurs : Relayers & Transactors.

1. Les Transactors créent leur transfert et diffusent le transfert sur le réseau. Le Smart Contract enregistre les données dans deux Merkle Trees (https://fr.wikipedia.org/wiki/Arbre_de_Merkle) :

• Les adresses dans un arbre Merkle
• Les transfers des montants dans un autre.

2. Les Relayers collectent une grande quantité de transferts pour créer un cumul. C’est le travail des relais de générer la preuve SNARK : ZKSNARK

La preuve SNARK est un hachage qui représente le delta de l’état de la blockchain. La preuve SNARK compare un snapshot de la blockchain avant transferts à un autre snapshot de la blockchain après transferts et ne signale que les modifications d’un hachage vérifiable au réseau principal :

(https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/)

Avant la création des ZK-STARK, les ZK-SNARK étaient utilisés pour créer des systèmes de preuve ZK, mais nécessitaient qu’une partie ou des parties de confiance configurent initialement le système de preuve ZK.

Ce point introduisait la vulnérabilité de ces parties de confiance compromettant la confidentialité de l’ensemble du système. Les ZK-STARK améliorent cette technologie en supprimant le besoin d’une configuration de confiance.

On l’aura compris, cette nouvelle preuve résout une des plus grandes failles de l’ancienne preuve SNARK. Cette preuve a été proposée par l’équipe de StarkWare dans son environnement Starknet que je présenterai par la suite.

Les STARK améliorent deux des problèmes des blockchains sans autorisation : la scalabilité et la confidentialité.

Les STARK améliorent la scalabilité en permettant aux développeurs de déplacer les calculs et le stockage hors chaîne. Les services hors chaîne pourront générer des preuves STARK attestant de l’intégrité des calculs hors chaîne. Ces preuves sont ensuite remises en chaîne pour que toute partie intéressée valide le calcul. Déplacer l’essentiel du travail de calcul hors chaîne à l’aide de STARK permet à l’infrastructure de blockchain existante d’évoluer de manière exponentielle tout en maintenant en toute confiance l’intégrité des calculs : c’est selon moi un gros atout pour le future.

Bien ! Vous avez maintenant toutes les clés en main pour rentrer dans l’ecosystème de StarkWare: StarkNet.

Starware x StarkNet

StarkNet est un ZK-Rollup décentralisé sans autorisation (basé ZKP) et utilise la technologie ZKSTARK pour se scaler de manière exponentielle sans compromettre la confidentialité.

StarkNet Alpha a été publié sur testnet public en juin et sur Mainnet en novembre de l’année 2021. Au moment du déploiement de Mainnet, StarkNet fournissait déjà un calcul général dans un état semblable à Ethereum.

Tout au long du développement, l’équipe de StarkWare a choisi une approche qui s’est d’abord concentrée sur la mise à disposition des fonctionnalités les plus importantes, partageant essentiellement le processus d’évolution avec la communauté.

StarkNet est loin d’être complet, mais même maintenant, les développeurs peuvent déjà créer des applications significatives et complexes. Aujourd’hui, il y a des centaines de développeurs qui s’appuient sur StarkNet, des dizaines de dApps et plus d’une douzaine d’équipes externes développant des outils et une infrastructure pour l’écosystème StarkNet (que nous verrons dans la dernière partie).

Une série de mises à jours a fourni de nombreuses fonctionnalités importantes. Plusieurs ont attiré mon attention :

• La messagerie L1 <-> L2,
• Les données on-chain et la prise en charge de la composabilité,
• La prise en charge des Events,
• Le mécanisme de tarification de base, la mise à niveau des contrats
• L’abstraction de wallet (qui sont désormais des Smart Contracts
• Le cadre de test, les outils de développement, la confirmation rapide

Depuis le début d’année, l’écosystème a atteint son seuil d’utilisabilité : il est possible de construire des dApps complètes et incroyables. L’équipe se concentrera désormais sur les performances du système : dans son état actuel, il est capable de supporter un débit limité de transactions. L’objectif est d’atteindre, d’ici le début du second semestre 2022, un TPS supérieur d’au moins un ordre de grandeur à celui d’Ethereum, à un coût inférieur d’au moins deux ordres de grandeur à celui d’Ethereum.

StarkNet doit être un réseau sans autorisation entièrement décentralisé, avec des mécanismes d’élection et de gouvernance des dirigeants. Atteindre cet objectif deviendra l’objectif principal une fois que le débit montera en flèche et que les coûts baisseront.

StarkEx est le moteur de mise à l’échelle de certaines des dApps les plus performantes utilisant L2 : dYdX(contrats perpétuels), DeversiFi (négociation et paiements au comptant), ainsi que pour Immutable X(IMX) et Sorare (NFTs) désormais.

Abordons maintenant la notion de Fractal Scaling : Layer 3 & plus

Le coût exorbitant des transactions sur Ethereum pousse de manière asymptomatique à laisser les L2 atteindre ces mêmes coûts. Le paradigme de StarkWare est que, les utilisateurs finaux mèneront la majorité de leur activité sur les L2 en raison des coûts de transaction considérablement réduits, du support croissant des outils DeFi et de la liquidité accrue fournie par ces dernières. Les L2 augmentent la scalabilité avec un coût de gaz réduit par transaction et des taux de transaction améliorés. Dans le même temps, les L2 conservent les avantages de la décentralisation, de la logique à usage général et de la composabilité. Cependant, certaines applications nécessitent une personnalisation spécifique qui peut être mieux servie par une nouvelle couche distincte : Parlons de Layer 3.

Un L3 se rapporte à un L2 comme un L2 se rapporte à un L1. Les L3 peuvent être réalisés à l’aide de preuves de validité tant que le L2 lié est capable de prendre en charge un Smart Contract Verifier (cf Partie 1). Lorsque les L2 utilisent également des preuves de validité soumises à un L1, comme le fait StarkNet, cela devient une structure récursive démentielle où le bénéfice de compression des preuves L2 est multiplié par le bénéfice de compression des preuves L3.

En d’autres termes, si chaque couche atteint, par exemple, une réduction des coûts de ratio 1000, les L3 en question peuvent atteindre une réduction de ratio 1M par rapport au L1, tout en conservant la même sécurité. On pourrait alors imaginer des frais de transactions qui coûterait une fraction du gas fee habituel.

StarkWare nous explique d’ailleurs les avantages d’avoir une Layer 3 :

• Hyper-scalabilité : tirer parti de l’effet multiplicatif de la preuve récursive.
• Meilleur contrôle par le concepteur de l’application de la pile technologique :

Performance et coût plus déterministes

Modèles de disponibilité des données personnalisés (par exemple, compression basée sur Validium ou spécifique à l’application des données en chaîne),

Fonctionnalité et vitesse technologique plus rapides (par exemple, introduction de nouvelles fonctionnalités qui ne sont pas encore prêtes pour la disponibilité générale).

• Confidentialité : ZKP appliqué aux transactions préservant la confidentialité sur une L2 publique.
• Interopérabilité : les L3 indépendants interagiront via le L2, et non le L1. Le L2 devrait évidemment être moins cher que son L1.
• L3 en tant que réseau “canari” à la Kusama pour Polkadot pour le L2 : de nouvelles innovations peuvent être testées sur les L3 avant d’être mises à la disposition du grand public.

De la même manière, on nous propose gentiment un exemple proposé par StarkWare pour exposer cette théorie d’un Layer 3 :

• Un StarkNet avec disponibilité des données Validium, par exemple, pour une utilisation générale par des applications extrêmement sensibles aux prix.
• Systèmes StarkNet spécifiques aux applications personnalisés pour de meilleures performances des applications, par exemple en utilisant des structures de stockage désignées ou une compression de la disponibilité des données.
• Les systèmes StarkEx (tels que ceux desservant dYdX, Sorare, Immutable et DeversiFi) avec la disponibilité des données Validium ou Rollup, apportent immédiatement à StarkNet des avantages d’évolutivité éprouvés au combat.
• Instances StarkNet de confidentialité (dans cet exemple également en tant que L4) pour permettre des transactions préservant la confidentialité sans les inclure dans les StarkNets publics.

Pour en savoir plus :

https://medium.com/starkware/fractal-scaling-from-l2-to-l3-7fe238ecfb4f

Smart Contract sur Starknet : Cairo

StarkNet est construit sur le langage de programmation Cairo, le premier vérificateur von-Neumann complet Turing de niveau production sur Ethereum. C’est en fait le langage des Smart Contracts sur l’écosystème. Cairo permet aux développeurs d’utiliser la puissance des ZKSTARK pour créer des applications scalables. Voyons ça de plus près.

Cairo : Smart Contracts

Cairo est un langage d’écriture de programmes prouvables : l’exécution d’un programme Cairo produit une trace qui peut ensuite être envoyée à un prouveur, qui génère une preuve STARK de la validité de l’instruction ou du calcul représenté par le programme Cairo. La preuve peut ensuite être vérifiée à l’aide d’un vérificateur.

Aujourd’hui, la plupart des dApps sont construites autour de Smart Contracts Solidity mettant en œuvre une sorte de logique & une interface, et un backend. Ces dApps, lorsqu’elles rencontrent du succès, sont inévitablement confrontées au problème de scalabilité.

De plus en plus, nous voyons des dApps qui résolvent leurs problèmes de scalabilité en se tournant vers des solutions évolutives L2 basées sur des preuves (comme DeversiFi avec StarkEx). Un composant hors chaîne prend en charge certaines des parties les plus complexes de la logique métier et communique avec les smart contracts on-chain, sans renoncer à la sécurité, car toutes les modifications de l’état du système sont certifiées par des preuves (ZKP). La scalabilité s’améliore car la vérification d’une preuve on-chain est exponentiellement moins chère que l’exécution de la logique métier entièrement on-chain.

Avec Cairo, les obstacles à l’utilisation de preuves pour atteindre la scalabilité sont beaucoup plus faibles : on écrit une logique en Cairo, puis le code doit être prouvé hors chaîne, et une fois cette preuve validée on-chain, on se retrouve avec une dApp qui peut utiliser le résultat en toute confiance — comme si elle l’avait exécuté on-chain.

Trois points coûtent cher sur Ethereum : le calcul, la transmission et le stockage. Cairo les résout tous les trois. Pour comprendre comment il fait cela, nous devons introduire un nouveau concept — The Shared Prover (ou SHARP).

Le SHARP est le lien entre votre code Cairo et votre Smart Contract Solidity. Il comporte trois composants principaux : un prouveur (hors chaîne), un smart contract de vérificateur (on-chain) et un contract de registres de faits (on-chain).

Le prouveur prend la trace d’exécution de votre programme Cairo, prouve qu’il est valide et envoie cette preuve au vérificateur. Après avoir vérifié la preuve, le vérificateur en chaîne franchit une étape supplémentaire importante : il écrit un fait attestant de la validité de la preuve dans le registre des faits. Ce fait est comme un sceau d’approbation sans confiance, certifiant que le programme Cairo a été calculé correctement. Maintenant, tout ce qui reste au contrat intelligent de la dApp est de vérifier que ce fait existe, afin de s’appuyer sur le calcul qui a été exécuté hors chaîne.

Pour rentrer plus loin dans cet environnement de développement, je vous laisse avec ce notion : https://seen-joke-82c.notion.site/StarkWare-Development-965f54711eb84dc79f3b61f22df9e383

Projets en construction sur Starknet : Must Follow

Mais alors, maintenant que vous avez tout compris sur le ZKP, StarkNet & Cairo, que faire ?

StarkNet Wallet : ArgentX

La première étape va être de configurer votre wallet. On utilisera ArgentX :

• download the chrome extension ou check their repo

Contrairement à Ethereum L1 où les clés privées et les comptes sont généralement la même chose (pensez aux portefeuilles EOA), StarkNet prend en charge l’abstraction de compte, ce qui signifie que chaque compte est en fait un Smart Contract qui doit être déployé avant de pouvoir interagir avec le réseau. C’est à la fois une opportunité fantastique et une complexité supplémentaire pour un utilisateur normal.

On utilise ici le wallet ArgentX pour s’abstraire de la complexité : il crée et sécurise des clés privées, déploie des contrats de compte contrôlés par des clés, se connecte à des applications décentralisées et envoie des transactions au réseau StarkNet.

Le fait d’utiliser un Smart Contract comme wallet est selon moi une grande avancée vers la sécurité. ArgentX propose de la même manière de créer des Vaults en temps que wallet (donc multisig automatisé). Toutes les transactions avec des adresses non fiables sont automatiquement bloquées, sauf si vous utilisez des tuteurs. Cette sécurité couvre tous les actifs & les transactions avec des adresses de confiance sont transparentes

—

Actuellement, les applications disponibles sont principalement sur la testnet de StarkNet, & pour les utiliser, il vous faudra récupérer des tokens de tests : https://faucet.goerli.starknet.io/

StarkNet Bridge

La 2ème chose la plus importante à savoir : comment transférer des fonds depuis un L1 (Ethereum) sur la L2 Starknet. La réponse se trouve dans le bridge StarGate :

https://medium.com/starkware/starkgate-alpha-35d01d21e3af

Nous resterons prudent cependant puisqu’il s’agit encore une fois d’une Alpha, pas encore auditée.

StarkNet DEX — AMM

On commence avec ce que tout le monde recherche lorsqu’on entre dans un nouvel écosystème / L2 : un DEX.

Actuellement, il y a plusieurs dApps qui se démarquent du lot :

• ZigZag Exchange : DEX

https://info.zigzag.exchange/

Un échange décentralisé construit autour du ZKP, avec un OrderBook.

• ZKX: Perpetual Trading

https://twitter.com/zkxprotocol

• Starkswap: DEX AMM

https://www.starkswap.co/ — https://medium.com/starkswap/the-starkswap-vision-6c73f8e66aab

Un échange décentralisé avec un Automated Market Maker

StarkNet Lending

• zkLend

https://linktr.ee/zkLend

zkLend est un protocole de marché monétaire basé sur StarkNet. ZkLend offrant une double suite d’autorisations des solutions axées sur la conformité pour les clients institutionnels (“Apollo”) et un service sans autorisation pour les utilisateurs retails DeFi (“Artémis”).

StarkNet Launchpad

• Zkpad

https://zkpad.io/

Comme d’habitude, selon moi l’un des points centraux d’un nouvel ecosystème : le launchpad. L’objectif de l’accélérateur ZkPad est de fournir aux fondateurs un soutien stratégique et opérationnel, y compris le co-marketing sur Twitter/Discord, les intros de partenariat et d’écosystème, l’accès à une base de données de talents sélectionnés, y compris les développeurs Cairo, les concepteurs UX/UI et les spécialistes du marketing. La plateforme est spécifiquement conçue pour ouvrir des opportunités d’investissement, autrefois réservées aux fonds d’investissement, aux particuliers.

StarkNet DeFi

• Magnety

https://twitter.com/magnetyfi

Magnety est un protocole de gestion d’actifs permettant à quiconque, tels que des groupes d’investissement, des DAOs ou individus de créer et gérer un fonds spéculatifs via l’écosystème Starknet & L1 DeFi. Le protocole permet de créer un coffre-fort hautement personnalisable basé sur sur une stratégie d’investissement que vous pouvez choisir. Selon moi un produit DeFi à suivre, hautement sécurisé grâce aux ZKP.

Vous retrouverez une liste non exhaustive de projets en construction sur StarkNet : https://starkware.notion.site/Projects-Building-on-StarkNet-a33dee55778a4515a9be9bdae02ee682

— — — — —

Pour plus me suivre & discuter avec moi :

https://twitter.com/0xExoMonk