A lot has changed over the years, but one thing has remained constant: an obsession with giving you the most powerful tools to make building production bots as simple and easy as possible. Our Silverback SDK library is the fastest way today to build powerful Web3 automation in Python for use cases such as monitoring, trading, on-chain DevOps, indexing, crypto payments processing, and more. Anyone, right now, can build any bot to do anything, for free, using the Silverback SDK, just checkout the docs at https://docs.apeworx.io/silverback. No login or payment required!

But now that its released and publicly available, you might be asking why Silverback is important? Why should I learn it and get involved? What will come next for the Silverback Platform if I build on it? Now that it is finally released, we can finally lay out our vision for what comes next!

First off, now that the Silverback Platform is live it means that hobbyists who have already been building bots with the Silverback SDK can finally run them on our rock-solid hosted infrastructure, and delegate all the pains of cloud orchestration to be Someone Else's Problem™. For most of our existing userbase, this is probably something you have been waiting since we first mentioned the Platform: easy-to-build Python bots, that run autonomously on rock solid infrastructure managed by someone else, letting you sleep easy at night without having to worry about node outages, bot errors, and whatever other terrors await you off-chain. But there are many more people out there that wished they could run these types of bots but don't have the skills to write a few lines of simple Python! Silverback should exist for them too!

This is where the Platform comes in: we wanted to make it easy for operators to manage the operation of tens to hundreds of bots easily without having to learn an ounce of Python. The Silverback SDK ships out of the gate with the tools necessary to package and publish your bots into Docker images that anyone can run, allowing workflows where developers can easily publish (and monetize!) their automations for others to run.

Imagine a hedge fund where traders can focus on complex filtering and trade execution, while data analysts can monitor existing strategies, all while partners have full control over the whole operation.

Imagine a talented Python developer who builds and refines popular actions such as token farming and arbitrage strategies for others to run on new protocols they are interested in (maybe even a hedge fund?)

Imagine building a complex FinTech application or integration with a larger traditional bank that simply leverages bots published by others for managing assets in popular DeFi protocols or monitoring for anomalies within their on-chain operations.

Imagine building a wealth of capabilities that a personalized LLM chat bot can use to evolve and execute your own bespoke market thesis, all without ever having to write a line of Python code yourself.

This is what the Silverback Platform unlocks, a storefront for Web3 automation and capability. A way to extend yourself on-chain and compete within this global movement!

Sounds interesting, doesn't it?

For the more plugged-in Crypto-natives and just plain-old skeptics among us, that might sound great but the next question you might ask is...

"Do I have to trust the developers and operators of this hosted infrastructure with my entire on-chain life?"

What if there is an outage where we are hosting the Platform's infrastructure?

What if we go rogue and start doing something bad with your data?

What if we go out of business?

How do I really trust this?

Well for this launch, we are the sole operators of the Platform, to make it even feasible in the short-term and unlock the capability for people to use it to host their bots. But that's not where we are going to stop.

One of the main promises of Crypto is unlocking massive coordination power, the ability to create much stronger and more resilient systems that can be relied on for years and decades to come. So today we are announcing our plans for the next stage of Silverback's evolution, transforming our centralized, hosted infrastructure into a fully-fledged decentralized infrastructure network capable of reliably and safely operating tens, maybe hundreds of millions of bots around the globe.

This will be a dramatic increase of the size and scope of Silverback's capabilities, and unlock countless use cases and even businesses where on-chain automation is the key ingredient to thrive. We are extremely excited to build this, and hope you are too. Stay tuned!

🦍 stronger together, with ApeWorX

Need help? Join our Discord where we can help you get set up and make the project of your dreams: https://discord.com/invite/apeworx

Let's go through everything:

One of the biggest struggles of smart contract development is balancing proper testing with speed. You can have the most solid contract code in the world but testing it will be nothing but a headache if you're forced to test it in a language lacking proper testing support. Ape framework solves this by allowing you to write full integration tests with the structured flexibility of python and pytest behind it, but for many tests doing a full provider construction, transaction, block mining, and tear-down takes too much time and can really add up in the full test suite.

Enter Titanoboa, a Vyper interpreter that Ape uses to streamline the testing of smart contracts by eliminating the need for transactions, signing processes, and reliance on provider applications.

Titanoboa simplifies this by running EVM opcodes directly, significantly reducing the overhead and drastically speeding up testing.

When you compile a smart contract, it generates Ethereum Virtual Machine (EVM) opcodes. These opcodes are the fundamental instructions that dictate how the contract operates within the blockchain environment. Typically, users interact with blockchains through transactions that include a "data" field, specifying which code to execute from the smart contract. This method is effective but introduces significant overhead during the testing phase. Most traditional testing tools require devs to manage private keys, sign transactions, and run developer nodes (Hardhat, Geth, Anvil, etc), slowing down the development and testing processes massively.

Ape-titanoboa is different. It runs EVM opcodes rather than relying on transactions, signing, or any of the above, lowering overhead massively.

By cutting out the transaction burden, Titanoboa allows for much faster execution of the smart contract logic, drastically speeding up the processes and cutting out a massive amount of time needed in the testing process.

Now you still can (and should!) do slower, full integration tests, but you are no longer forced to.

Here's an (almost) complete rundown of the pros/cons of Titanoboa:

• Faster Testing: The primary benefit is speed; developers can test their code more quickly, leading to more iterations and improvements.

• Reduced Overhead: The elimination of transaction-related complexities makes it easier to focus on specific logic within smart contracts.

• Enhanced Testing: Titanoboa makes it easier to test your smart contract's specific logic and target specific parts too ensure they run the way you want them to.

• Simplicity: Developers can focus on testing specific functionalities without getting bogged down by transaction mechanics.

• Flexibility: Titanoboa provides tools to manipulate execution blocks and timestamps, enabling more dynamic testing scenarios.

• Realism Issues: Because it cuts out some transactions, some aspects may not reflect real-world scenarios accurately.

• Potential Bugs: Running code in a simplified environment may expose developers to bugs that wouldn’t appear in a fully integrated system.

• Limited Integration Testing: While unit tests can be executed quickly, integration tests are still necessary to ensure you're fully covered.

While it may not fully replace regular testing completely (especially for integration testing) Boa is basically the new testing standard and an incredibly powerful tool to streamline development and for actually making your project a reality.

Integrating Titanoboa with Ape Framework

There's three key things to understand about this integration:

1. TestProviderAPI: This API includes essential methods like set_balance(), pending_timestamp (which lets you manipulate time) and mine() which controls blockchain changes during testing.

2. The Titanoboa Plugin itself: The new plugin processes transactions directly by executing EVM opcodes and returning a computation-wrapper akin to receipts (which can even implement the ReceiptAPI).

Using these alongside your regular Ape tools will let you try out ape-titanoboa, letting you cut out the cruft and test what you want to test as fast as possible.

To show just how much of an improvement ape-titanoboa is, lets test it with our tool ApePay using both ape-foundry and ape-titanoboa:

As you can see, its no contest. In our other tests it reached up to +2x speed increases (and we aim to bump that up even more with the upcoming updates).

People say that speed is a luxury or a frill, but in reality it's a necessity in the world of crypto development.

Tools like Titanoboa allow you to have quicker testing cycles, focus on actually building vs waiting around, and let you avoid getting bogged down by unintuitive processes like writing tests in Solidity. One of our goals this year is to become one of the fastest frameworks, not only the most customizable one.

If you want to experience the newer, faster, Ape+Titanoboa, download it here: https://github.com/ApeWorX/ape-titanoboa

Need help? Join our Discord where we can help you get set up and make the project of your dreams: https://discord.com/invite/apeworx

🦍🤝🐍

In this guide, we’ll walk you through the steps to clone an ERC4626 bot project, configure your environment, and run a bot built using the Ape Framework and Silverback. Because of how the yield is abstracted into a token it becomes harder to figure out how much true yield the protocol is generating vs what's stated on the protocol or issuers site. This means that unless you’re calculating the returns you’re getting from an ERC-4626 token every day then you have to trust that the posted yield is what you’re actually getting. By the end of this tutorial, you’ll be able to observe real-time Ethereum block data and vault share prices right from your terminal.

But this is crypto. Trust is bullshit. Here’s how you can build a bot to verify the yield for you.

Silverback is a framework designed to help you create bots that interact with the blockchain. It simplifies tasks like:

• Listening for events (e.g., new blocks, transactions)

• Fetching live data (e.g., token prices, vault share values)

• Automating DeFi strategies( Advance )

You can easily run your bots with a minimal amount of code while taking advantage of Silverback's modular design and asynchronous task management. Let’s dive in!

The bot you're setting up is a price checker for an ERC4626-compliant vault. It listens for new blocks on the Ethereum blockchain and retrieves the current share price from a vault every time a block is mined. Specifically, the bot does the following:

1. Monitors New Ethereum Blocks: It uses the Silverback framework to listen for block events in real-time on the Ethereum mainnet.

2. Fetches Vault Share Price: Each time a new block is created, the bot queries the share price of the ERC4626 vault. The share price represents the value of vault shares, which fluctuate as assets are deposited, withdrawn, or accrue yield within the vault.

3. Logs the Results: The bot logs the block number, block hash, and the updated share price, allowing users to see how the vault's value evolves with each block.

In simple terms, this bot provides live data on the value of an ERC4626 vault, giving you insights into how the vault performs in real-time as transactions occur on the Ethereum network.

The code for this project is available here

First, let’s clone the repository from GitHub make sure your copy the demo branch

git clone https://github.com/ApeAcademy/erc-4626.git
git checkout remotes/origin/demo
cd erc-4626

This project contains all the code necessary to run a bot that interacts with ERC4626-compliant vaults.

In this tutorial I export the variable in my cli session so I don't have to create an .env file. Here is how to to do that:

export WEB3_ALCHEMY_PROJECT_ID=your-alchemy-id
export ERC4626_VAULT_ADDRESS=your-vault-address

echo $WEB3_ALCHEMY_PROJECT_ID
echo $ERC4626_VAULT_ADDRESS

Replace your-alchemy-id with your actual API key from Alchemy, and replace your-vault-address with the address of the ERC4626 vault you want to interact with. I used a yearn vault ERC4626_VAULT_ADDRESS=0x583019fF0f430721aDa9cfb4fac8F06cA104d0B4

Next, we need to install the required Python packages and Ape Framework plugins. Run the following command:

pip install -r requirements.txt
ape plugins install . -U

This will install Silverback, Ape Framework, and any other dependencies required to run the bot.

Ensure your ape-config.yaml file is configured to use Alchemy as the default provider for Ethereum mainnet. If you want to learn more how to configure your ape-config.yaml

If you cloned the project you ape-config.yaml should look like this:

name: ERC4626
plugins:
  - name: vyper
  - name: alchemy
  - name: etherscan

ethereum:
  default_network: mainnet
  mainnet:
    default_provider: alchemy

With one simple command you can run the project with:

silverback run bots.silverback_yield:bot

The bot will start monitoring Ethereum blocks and printing out the share price of the ERC4626 vault every time a new block is mined. Here's a sample output you can expect:

Price Event: 0.9547177472995926
SUCCESS: update_shareprice[block_number=20915791,block_hash=0xb0b2215bce3801b0412e39b75eb73ef2f7ad8d9618c32d1460086c1cb41ed9eb] - 0.340s (2.6%)
Price Event: 0.9547177355383596
SUCCESS: update_shareprice[block_number=20915792,block_hash=0x27c1c49273640ac02ea87ed934fa7dd367aea4803005373b1b13d0c34201600a] - 0.360s (2.8%)

Below is the core code for our Silverback bot that monitors an ERC4626 vault:

import os

from ape import Contract, chain, networks
from silverback import SilverbackBot

bot = SilverbackBot

with networks.ethereum.mainnet.use_provider("alchemy"):  # or "infura"
    vault = Contract(os.environ.get("ERC4626_VAULT_ADDRESS"))

one_share = 10 ** vault.decimals()


@bot.on_(chain.blocks)
def update_shareprice(_):
    """
    Convert shares to a set price unit.
    """
    price = vault.convertToShares(one_share) / one_share
    # Total number of shares in the vault divide by 
    # the current unit price of a share  = gwei 
    print(f"Price Event: {price}")

• Network Connection: The bot connects to the Ethereum mainnet using either Alchemy or Infura as the provider.

• Vault Contract: The Contract object connects to the specified ERC4626 vault via the contract address defined in your environment variables.

• Price Update: The bot listens for new blocks (@bot.on_(chain.blocks)) and triggers the update_shareprice function every time a new block is mined. It retrieves the vault’s current share price by calling the convertToShares method on the vault contract and logs the price event.

• Cluster: In the cluster, if you return data from one of the handlers, the cluster will collect that data for later review

• Missing .env file: Ensure your .env file is in the root of your project directory and formatted correctly.

• Provider Errors: Double-check that your WEB3_ALCHEMY_PROJECT_ID is correct and that you’ve set the correct default network in ape-config.yaml.

• FileNotFoundError: If you get an error related to missing directories, verify that your bots/ folder is in the root of the project.

Now that you’ve successfully set up and run your first Silverback bot, consider expanding its functionality:

• Track Multiple Vaults: Extend the bot to monitor multiple ERC4626 vaults at the same time.

• Automate Transactions: Add logic to trigger a transaction when certain conditions are met, such as depositing or withdrawing assets based on share price thresholds.

• Notify Users: Integrate email or messaging alerts when certain events occur, such as a significant change in vault value.

With Silverback, you’re not just limited to monitoring prices—automating DeFi strategies is just as easy!

Check out the main branch of this demo, it has advance yield calculations for a year's worth of time. It uses a local database via SQ-lite to store the data. The data can accessed by a bot on a Silverback cluster to perform strategies such as liquidate, buy, sell, and so much more.

One of the most groundbreaking changes in the Ethereum ecosystem was the creation of ERC-4626, a method for tokenizing yield earning vaults.

• ERC-4626 Standard

• ERC-4626 Ape Explanation

Yield is abstracted into a token it becomes harder to figure out how much true value the protocol is generating vs what's stated on the protocol or issuers site. This means that unless you’re calculating the returns you’re getting from an ERC-4626 token every day then you have to trust that the posted yield is what you’re actually getting.

Subscribe so you can see the next tutorials where we teach you everything from how to make an automated trading bot to building a bot that scans the chain in real time to one that makes a hotdog powered stablecoin.

Also if you want the latest on Silverback and to see our experiments, join the hidden Telegram chat where we post our latest tools and tips on botcrafting so you can build your robot army:
Telegram Silverback

If you want more Apey goodness, check out our Discord where we go deep into the Ape Framework, crypto engineering, and how you can customize your setup to let you work faster than you could ever have imagined.
ApeWorX Discord

Ape Scream

At ApeWorX we're used to creating bots and plugins to serve a useful purpose and make people's lives easier.

So as a break from all that we thought "What's the silliest Silverback bot we could make?" and came up with the idea of making a bot that screams into the void every time you make a transaction.

My name is Chris, and in this tutorial I'm going to show you how you combine Warpcast Frames, Generative AI, Vyper and Silverback to make a unique picture based on specific conditions on the blockchain and post it to Farcaster

To follow along with this project, clone: https://github.com/ApeAcademy/SilverbackEcho

The inspiration for this project came from a Telegram channel called Bear Market Screaming Therapy, dedicated to audio messages of people screaming. I wanted to automate a similar concept using Silverback and Farcaster.

Perfect. Now let's put it on chain (or at least a testnet).

This project involves integrating a simple Vyper contract called echo.vy with a Silverback bot connected to Warpcast and a Generative AI service to post a unique picture by watching for an Event to emit a Received message.

Basically on-chain void-screaming

Hollaback.py is the Silverback bot itself. This is shinning star of the whole project. If you take away anything from this, it is this right here. This tool can be expanded on and to form so many projects integrating the off-chain and on-chain worlds. So let's breakdown the code:

from silverback import SilverbackApp

# Initialize the Silverback app first
app = SilverbackApp()

We want to trigger our logic based off of the event we want to watch. To do that, we add the a decorator @app.on_(my_contract.Received) to define what we are going to watch for from on-chain.

For more help on creating an application, see the Silverback Docs

Initializing the app creates a network connection using the Ape configuration of your local project, making it easy to add a Silverback bot to your project in order to perform automation of any necessary on-chain interactions. We will keep this app in a separate folder called bots/.

When the event Received is emitted, we are going to cast a message "AH" with the number of H's based on an equation we made (text="A" + "H" * floor(log2(log.amount))), if the amount of wei in the log is >= 0.001 ether. We will cast the message using client.post_cast(text=scream).

Here is the simplified code:

from ape import convert
from ape_farcaster import Warpcast
from silverback import SilverbackApp

app = SilverbackApp()
client = Warpcast(app.signer)


@app.on_(my_contract.Received) # defined what event to watch
def payment_received(log): # execute this on every log
   client.post_cast(text="A" + "H" * floor(log2(log.amount))) #A + xH do the math, and then using the post_cast(text=AHHHHH)

In order to make this project more appealing and creative. We are going to add some creative ways to generate some fun.

client.post_cast(text="A" + "H" * floor(log2(log.amount))) is the single line of code to publish a message to Farcaster. Casting an image requires client.post_cast(embeds=<direct_url_link_to_image>). So the game plan and puesdo code goes as follows:

app.on_(my_contract.Received)
def payment_received(log):
   client.post_cast(embeds=<direct_url_link_to_image>)
"""
log provides 2 values address of sender and amount of weth sent.
1. create prompt
2. create image(prompt)
3. upload image to Pinata
4. Cast message with address of sender and image 
"""

def create_prompt(number_adj: int) -> str:
"""
1. This method creates a prompt based off of the address sending eth.
"""

def createImage(prompt) -> str:
"""
 2. Creates an image based off the prompt.
"""

def uploadToPinata(image):
"""
3 . Uploads image to pinata and returns an ipfs hash.
"""

Creating the prompt uses a library called wonderwords this helps us generate adjectives to fill in the prompt " An ape {adjective_string} ape that is screaming AHHHHH".

Using the Stability.ai documentation on how to create an image via post request we imported our own API key and the prompt and return the file name of the generated image.

Note there is a chance that the prompt has a word that is not approved so that is why we have the prompt in a 10 try for loop.

Once the image is created, it needs to be uploaded to a place where a direct link to the image can be referenced. We decided to use Pinata.cloud to host it since it is easy to use. I used a combination of their docs and stackoverflow to find a way to pin a file to ipfs.

At this point, you understand how the whole hollaback script works and you just need to let the magic fly!

To run the project: first deploy the Vyper contract using this tutorial to deploy contracts. Since we only need to deploy this contract once, I just use ape console --network :sepolia and then record the contract address emitted by the script.

Then, run the Silverback App via silverback run bots.hollaback:app --network :sepolia --account <your Farcaster address>. Finally, to trigger the interaction, use ape run holla --network :sepolia --account <your payment account> in a separate terminal. The Silverback App will monitor the contract event emitted when you run the holla script, which will trigger the post as long as the conditions are met.

And ta-da! You now have a bot that you can use to vent your frustration and tokenize any and all existential crisis.

If you want to learn more about Silverback feel free to check out our Discord, and if if you liked this tutorial you'll love our tutorial on how to build a defi app like an aerospace engineer.

I know as well as anyone that if you ask any type of seasoned developer, whether they are protocol developers that need to integrate with other applications, security researchers trying to understand the impact of potential bugs, or really just anyone trying to get an ABI to interact with a contract from a web page or python script, you will hear a litany of issues related to figuring out what the source code is and how to compile it and publish it correctly. It is probably the single biggest issue holding us back from truly making accelerated progress as an ecosystem, and is probably Ethereum's worst original sin that there was not a consistent way to share this information from within the protocol.

I probably can't sum up the current state of affairs any better than banteg has:

banteg

@bantg

package manager wars is better than the status quo. hope this will be distilled to something good soon. it’s in everyone’s interest.

señor doggo 🏴🏴‍☠️ in his wartime ceo era

@fubuloubu

Yet another federated package system that is not aware of other package systems (etherscan, VERA, blockscout, etc.), or languages (vyper, huff, fe, etc.)

19

5:20 PM • Jun 7, 2024

However, the biggest problem of them all is that there is a fundamental disagreement about what we can do about the problem. Many people think we just need one more tool to rule them all, but that's wrong because we already have dozens of tools with dozens of slightly different ways to accomplish the exact same tasks within different frameworks, and regardless no single tool is going to solve this problem sufficiently well for everyone. Some people think we just need to focus on how the data is being hosted, as if yet another SQL database is the solution to the problem, so long as we can force everyone to use a single database to reduce the problem to one that we can solve. A few out-of-the-box thinkers think that we can just leverage existing tools in specific ways to solve the problem better, and for the most part they are correct, except in small ways where we do have a specific set of requirements that most existing tools do not account for well.

No, the real problem is simply a problem of coordination, and we are not alone in having it. When you look at other programming language ecosystems, such as Javascript and Python, you can't un-see this coordination problem because the root cause is that developers think they can simply build their way out of the problem, and they don't realize that the first step to recovery is just deciding to work together and acknowledge that such a problem exists in the first place.

It is only with this enlightenment we can actually work to build solutions that truly push the needle.

Okay, so we've taken the first step of admitting we have a coordination problem, what do we do next?

The second step in solving a coordination problem is finding the shape of the problem. Earlier this year, we interviewed several prominent teams who were building at different parts of the packaging spectrum about their processes, problems, and ideas they had for solutions. We collected the results and made an analysis of them, and recently published that here:

https://github.com

GitHub - ApeWorX/ethereum-packaging-interviews

Contribute to ApeWorX/ethereum-packaging-interviews development by creating an account on GitHub.

It is suggested that you read the report for more information, but we can summarize a few of the points:

1. Make finding sources, compiler settings, and build artifacts (such as ABIs) as trivial as possible

This one was our top finding. Almost everyone agreed that one of the biggest issues with DevEx across the entire stack is that it is difficult to find the information needed for downstream projects quickly, reliably, and correctly. In fact, they ranked it as the single highest issue preventing greater ease of developing new and innovative projects with smart contracts, for newcomers and advanced users alike.

2. Make the solution flexible enough to handle complex environments, via old and new tools alike

There is quite a lot of history now to EVM development, and one of the biggest problems to any potential solution these days is it must be able to flexible enough both to handle past projects, and also "level up" Ethereum DevEx with new innovations for years to come. If it's not flexible enough, really it won't be as useful as it could be within developer's stacks as they work on increasingly complex projects, so the value proposition is not there to justify upgrading. Also, if it's too difficult to use, that will also be a barrier to adoption, and prevent us from getting the results we need to in order to create better patterns of behavior and unlock better DevEx for more advanced use cases.

3. Avoid centralized chokepoints, but also avoid DevEx issues that decentralized solutions have

One of the biggest issues preventing greater use cases with smart contract data today is that the data ends up in centralized silos, from which it's hard to query across. If we want to be able to unlock massive wins on security and developer tooling, we need the ability to obtain large sets of smart contract data for machine learning, security trend analysis, and more. However, acknowledging that the data today lives in federated repositories which are already quite sticky to end-users, we need to create a pathway for greater interoperability of that data without accidentally threatening perceived competitive moats. In other words, our solution needs to show existing participants in our ecosystem why having a slightly smaller piece of a much larger pie is good for all of us.

If we use these desires as the starting point for assessing potential solutions to the problem, we can be sure that we will find something that most people find easy to use, flexible and powerful, and also compatible with all the ways that users want to interact with the data, both now and in the future.

The next step in finding a solution to our problem is that we should assess what current solutions already exist, and compare/contrast them to see if we can find areas of improvement or requirements a new solution must have to be compatible with what users have come to expect.

In terms of current solutions, there are couple of ways that people build and share sources, compiler settings, and build artifacts today:

1. Publish their project to Github, usually just the sources, framework-specific compiler settings, and dependency information that other tools have to add custom handling if they want their own users to download them as dependencies within their own projects

2. Publish their smart contract code build via block explorer verification, either by flattening code or through multi-file verification (in both cases manually specifying compilation settings), which others (primarily security researchers or those scripting in non-EVM environments) can consume

3. Manually create some build artifacts locally to try and match what is expected to interact with on-chain (for example, using Curve from a Solidity project, or working with a contract that has a corrupted ABI published on etherscan or no ABI at all)

There are also a couple of recent developments we can check out:

4. Soldeer shipping foundry-specific package management as a core feature within Foundry

5. Vyper v0.4 will ship with a zip archive-based packaging of an existing project's sources and settings for near trivial rebuilding of any vyper contract (such as for verification purposes)

Additionally, we can think outside the box and compare our needs to those other open source packaging communities have adopted:

6. NPM, PyPI (and other language communities) have quite large and successful repositories of source-available package data useful for composing within other projects using standards

7. nix is a functional language that allows specifying how to build packages from scratch reliably and without dependency issues because you specify complete dependency information

Lastly, there is also EIP-2678 (aka EthPM v3), which was an attempt to solve this problem many moons ago, and (as I stated before) is in use within Ape (albeit in a slightly-modified form) to a great degree of success in reducing pain emanating from a multi-framework universe of different build systems we need to handle for our users.

Obviously, one of the biggest differences in comparing our needs to those of the packaging systems in use by some of the biggest language communities is that our ecosystem is inherently multi-language, meaning we have to take all comparisons with a grain of salt because we are well past the point where focusing only on a single language community is even practical for EVM development (with the rise of Vyper, Huff, many new language communities being built for L2s, etc).

That makes the recognition of something like nix interesting because it is inherently language-agnostic, which is critical for us both in terms of the EVM language we want to work with as well as the way we want to consume this information (for use within frameworks and devtools written in JS, Python, Rust, Go, etc.), and is basically a requirement for any prominent EVM devtool in this day and age. Still, something like nix may be way overkill for what we need as it's not always practical to ship what is essentially an entire functional OS as a dependency in all the different environments we need to work with today (such as the web browser).

What these all have in common though is that there is a single common package specification, so that even if multiple tools or languages are used, we can be sure that they work with the same data in a context-independent manner, no matter what tool is currently en vogue (and what other tools are no longer in style that we still need to work with).

This is what building in a future-compatible way looks like.

The second thing we can see is that there is a stark divide between "filesystem-like" archive formats (e.g. git/Github, PyPI/NPM, soldeer/vyper v0.4 zip archives, etc.) and "virtualized" document formats (e.g. JSON documents from REST APIs like etherscan, EthPM, etc.) that we can work with. It's also worth noting that while REST APIs (which communicate via JSON documents) can obviously be a convenient way to index and share metadata for packages, it's not actually a convenient way to share source files or even hierarchical information about file layout for reproducing a build. All "virtualized" formats end up needing to "re-create" the filesystem context based on the metadata that it has, which may run into difficulties where such metadata is under-specified.

Since most successful implementations of this idea use an archive format (the most common of which is a zip archive of a particular folder structure, with defined files in it, where the archive has a special extension), we probably want to use the same thing in our solution, but also be smart about what metadata we want to expose for easy access within the archives, for use cases such as querying packages from a repository or pre-determining what build artifacts we will have access to once we completely build the package.

Which takes us to...

We likely have yet more to do in inventorying, analyzing, and finding patterns vs. what exists out there, but I am gonna walk through what comes next after we do that. Namely, everyone's favorite XKCD comic:

But seriously, we can already see that creating a standard will be an extremely useful to formally specify a format so that other tools and languages can use it, and we can avoid siloing information and unlock the potential that broad accessibility to smart contract data can give us. Thankfully, we already have the EIP process for doing this (most likely should be developed as an ERC), as well a previous examples (namely EthPM v1 v2 v3) that we can use to reference what information was deemed important to share in the past.

Since we are already talking about departing from the previous standard and adopting an archive-like format instead, we can probably not tether ourselves to the mistakes designs of the past and also establish a more reasonable scope for what such a format must satisfy and what it can leave up to future iteration. This will likely take many months, inevitably some bikeshedding, and likely a hot discussion or two, but ultimately what we are building is a strong, framework-independent, multi-registry compatible format that we can start to use to solve production issues, and not just for one particular user or use case but across the whole ecosystem. Doesn't that sound great?

The last step in our journey is getting (mass) adoption of our new standard, which is where it goes from being another unfortunate piece of roadkill in a long list of poorly adopted Ethereum devtool standards, to ultimately what we need to hyper-accelerate Ethereum DevEx and create the smart contract data packaging of our dreams! Probably easier said than done, but fortunately we have already interviewed many major players in the Ethereum dev stack to get their input.

The only question that remains to be answered by them (and you, reading this article) is:

Systems that have to adapt and respond in real-time have to take special care not only to ensure that they are reacting as quickly as they can, but that the way they are acting, especially under the presence of faults and uncertainties, produces a reliable and stable outcome no matter what else is happening around it. You may even be surprised to learn that the number one determination of safety in these types of systems is actually not how fast they react, but rather how they ensure they have the most correct response despite dealing with adverse conditions and having a limited time to make decisions.

You can actually think of application blockchains like Ethereum as real time systems. They respond to complicated conditions and dynamically adjust to the presence of faults, almost entirely without any human intervention whatsoever. But let's focus on what makes them actually "real-time" in the sense of being a system that has to maintain liveliness no matter what else is going on, because some of the best properties that make Ethereum an attractive place to use for serious, high-valued applications are the reliability and fault tolerance emanating from this design principle.

There are plenty of examples of real-time systems where not making a decision in a timely manner critically affects how safe the system can actually be. Airplanes for instance are some of the most critical and high-reliability systems we interact with on a regular basis. When flying, airplanes have to make quick adjustments to their flight control surfaces in response to unpredictable and often chaotic movements of air around them that if left unchecked for too long would lead the airplane to tumble out of the sky and crash. Quick, timely inputs are absolutely critical to flight safety.

To account for this, aerospace engineers design their systems with hard real-time constraints, meaning that no matter what happens with the software it must always respond within a short time period or it will risk losing control of the entire aircraft. This property holds even if it means abandoning a calculation you have already started but not completed yet, as a result provided after the expected deadline is essentially useless to maintaining control.

Not all real-time systems need to maintain this level of strictness however. Sometimes, while we still do care about timeliness in a relative sense, but we can be a little flexible on the actual deadline so long as it means we are providing a correct answer, as long as that answer doesn't take too long to compute. In fact, we can describe this as more of a spectrum: the longer it takes, the less useful the computation will be to the system, but that usefulness is not black and white like it is with hard real-time systems. We call this type of system a soft real-time system.

We could describe blockchains like Ethereum as being soft real-time systems because while they do generally target consistent block confirmation and slot finalization times, they can occasionally not come to consensus for time periods a little longer than their targets and still maintain adequate safety. Still, their timeliness guarantees are important, because without them the lending and borrowing systems, margin calls, liquidations, oracle price updates, etc. become a little too out of date, and those applications dependent on those system-level guarantees inch closer towards catastrophic outcomes.

While speed is nice because with more speed we can fit more computations, as we said before, the primary determination that a system will be successful in it's goals is that it is capable of delivering consistent, reliable, and timely results. If you have a system that produces a burst of computations at random times, and is not capable of scaling to meet that demand within the time period required, it could overrun the expected deadline, which to a soft real-time system may mean that the results you produce could be considered out of date by the time the actions are taken. In the context of a smart contract application that runs on an application blockchain, if we take longer than a full block period to produce an action in response to some conditional trigger that we'd like to land in the next block, then our action may no longer be consistent with the state of the blockchain where we decided to take that action if it takes too long.

How we design off-chain systems that interact with on-chain ones should also reflect this principle. That doesn't mean we should go out and pick the fastest tools for the job always, because what works most of the time may not work in periods of high demand. We should build off-chain systems that scale well in response to events on-chain, so that when those times come, we are ready for them. This may mean picking algorithms and architectures that emphasize more of an approach of performing measurements continuously in parallel with actions that we want to trigger based on those measurements. Searching for a good opportunity to act in a real-time system is actually more about anticipating the best move to make next, vs. blindly reacting to every event that is happening in an effort to keep up with others.

No thought piece would be complete without a good shill, and I really started thinking about writing this short article in response to a discussion on the design principles of our upcoming Silverback Application Platform product with my development team. As people are starting to build out their own applications using the fully free and open-source Silverback SDK (you are trying it, aren't you anon?) we hope they will incorporate some of these design principles in their work and remember to always pick the solution that favors timeliness and correctness over speed and algorithmic complexity. Sometimes it really is the slow and steady that wins the race!

Happy hunting apes

Ape has you covered: All about coverage Part 2

Before you start delving into the practical aspects, it is essential to understand the concept of code coverage. If you are unfamiliar with coverage, we recommend referring to our first article on the subject.

The latest update, version 0.6.13 of Ape and version 0.6.9 of ape-vyper, introduces the coverage support exclusively for Vyper contracts. However, since Ape is a plugin based framework, this system facilitates adding coverage support for other languages, such as Solidity and Cairo.

So without further ado, lets dive in:

In this article, we are going to employ a Token contract as an illustrative example to showcase the functionality of coverage. You can follow this link here for the repository.

Utilising coverage functionality within the Ape framework is straightforward. You can initiate coverage by including the `--coverage` option when running `ape test`. This will generate a comprehensive coverage report. It is worth noting that certain types of coverage will require a provider plugin that supports transaction tracing such as `ape-hardhat` or `ape-foundry`.

https://docs.apeworx.io/ape/latest/userguides/testing.html#contract-coverage

This is our token contract for this example:

Currently we have not set any tests for this contract so our coverage will show  0%.

Ape shows the name, statements (Stmts), misses (Miss), coverage (Cover), and functions (Funcs). This is modelled after coverage-py and pytest-cov style reports.

• Name: Name of the source identifier

• Statements (Stmts): Amount of statements present in each contract

• Misses (Miss): Amount of statements not covered in tests

• Coverage (Cover): Percentage of the contract that is covered by tests

• Functions (Funcs): Percentage of functions/methods that are tested in each contract

A statement is either a group of values that have the same line numbers in a source file or it is a value with an extra tag to identify builtin logic that is injected by the compiler (such as the default or fallback method).

The coverage report is normally generated in the terminal but you can also generate the coverage reports as an external XML or HTML files by configuring them in the `ape-config.yaml` like:

You can also see a more verbose coverage report by setting the field `terminal` or `html` to include `verbose: True`. Verbose outputs are useful when you are trying to find the missing areas to cover. This will break down each contract to show each function and how well the functions are covered individually.

This will result in the following output for our contract `TestToken.vy`:

The `_*builtin*_` functions listed under your contract coverage functions are the functionalities that the compiler uses internally that are not in the source code, such as non-payable checks, safe-math checks, and the not-implemented contract default method check. Tests for these conditions are necessary to get to 100% coverage

Like gas reporting, you can also exclude contracts and methods from tracking coverage using your `ape-config.yaml` file.

You may want to use exclusions for methods or contracts that you don’t plan on pushing to production but are still using for debug or testing purposes.

We will be excluding the `DEBUG_mint` function from testing.

Now let’s try and add some coverage for our `TestToken.vy` contract.

Some methods will show zero statements. One example with a zero statement may be from an auto-generated getter method for a public variable: certain versions of Vyper do not contain source mappings for these methods. However, Ape will still check to see if this method has been called in your tests. To get 100% coverage, you must call these methods in your tests.

In this case, these will be methods like `name()`, `symbol()`, `decimals()`, `totalSupply()`, `balanceOf()`, and `allowance()`. A simple example of tests that you can make for these are:

By just adding this test, the coverage report for the TestToken contract will now show:

So now all we need to do is to add tests for the other functions: `approve()`, `transfer()` and `transferFrom()`

By incorporating these small tests, our test coverage will now reflect that we have 100% coverage for these functions.

However, it is crucial to recognise that achieving full function coverage does not guarantee thoroughness in testing your contract.  “Are these tests adequately comprehensive for my contract?” While the introduced test may offer substantial coverage, it is important to acknowledge that they may not encompass every possible scenario in which your contract may execute. Even with diligent testing and high code coverage, there is always room for enhancement. The journey towards code perfection is a continuous one.

Currently we only support statement coverage right now, if you were to add branch coverage, it would show less than 100% for total coverage.

One more thing to note is that some methods may have a full method signature while others do not. Methods that have the full signature mean that their short name is shared with other methods. This happens in Vyper from auto-generated kwarg-based methods, or in Solidity when overloaded functions are added. Thus, the full selector is used to distinguish the methods in the coverage (and gas) reports.

Remember in our previous article that we said “Code coverage metrics, as a percentage score, are really telling you very little about whether your code is doing the right thing.” Writing an abundance of tests is not the sole objective.  Instead, it is crucial to focus on crafting tests that align closely with your specific objectives, ensuring optimal suitability and effectiveness. The coverage tool serves as a means to gauge the extent to which your code has been thoroughly exercised with these examples, or guide you towards areas that need more attention.

We trust that this article has provided valuable guidance on harnessing Ape's new coverage feature to prepare your contracts for production deployment. It is important to remember that while coverage is an invaluable tool, it should be supplemented with other methodologies to ensure the overall safety and security of your contract.

Consider complementing code coverage with techniques such as fuzzing, red teaming, and exploring unconventional attack vectors. By adopting a holistic approach to testing and security analysis, you can fortify your contract against potential vulnerabilities and mitigate risks effectively.

Embrace the power of comprehensive testing strategies and exploit the full potential of code coverage as a part of your robust development and deployment pipeline.

Thank you for reading and enjoy our coverage tool!

- ApeWorX

For the latest on all things Ape follow us on: Apeworx.io | Discord | Twitter | Bluesky

In fact, just the other day someone shared this with me:

https://twitter.com/jessewldn/status/1683805696297406465?s=20

But no one ever tells you how to actually do it. How does one shift their skills, thought process, and mindset away from building and launching projects rapidly to building them like they’re flying to the moon? Where’s the handbook for learning how to do this? Why can’t anyone tell me?

*Crickets.*

Well, thankfully, I actually happen to have a background in both hardware engineering and building aircraft, and I’ve also been working on building smart contracts for almost as long as my previous career as a flight control engineer. I’m gonna give you all the secrets that no one seems to want to share about how to build projects that always work, never get hacked, and make you millions in the process.

…

Okay, so I can’t actually do those things, but I have your attention now don’t I?

Alright, what are these pearls of wisdom?

It’s just reality.

All software projects have failures. What sets apart good projects from great ones isn’t how perfect the code is, or how much was spent on audits, or even how big the test suite is; it’s way simpler than that:

It’s planning for failure before it happens.

If you can’t reason about and rattle off a dozen or so failures that could happen when launching your brand new application, you’re doing it wrong. The weeks you spent working on gas optimizing your code so that it’s as efficient as humanly possible would be better spent making sure that you not only understand in what practical ways the code could have a failure, but also what mitigations you may have (or make available to your users) so that the impact of those failures is as minimal as possible.

In aerospace engineering, one of the tools that gets used is to conduct a FMECA (or Failure Modes, Effects, and Criticality Analysis) study of the system, identifying all the possible failures that the system can have, for all of the complex components within the system. This analysis is performed during the design phase of the project to ensure that there are protections and mitigations in place for when different types of components (hardware, software, hydraulic, electrical, etc.) have some fault that affects their operation and impacts other components around them.

Typically, this process leads to designing physical redundancies and failure handling into the system, so that in case an issue occurs, the system has an adequate chance at surviving the incident, as well as minimizing damage to itself, it’s environment, and the occupants inside. This process leads to the creation of a FHA (or Functional Hazard Assessment) which is the high-level overview of the major faults that bubble up from the FMECA study, and what the likelihood and impact of any critical events would be. All of this analysis occurs in the design phase of the aircraft, meaning years before you even get to build your aerospace project, you are aware of every single major fault of the system that could ever happen in practice.

Thankfully, smart contracts aren’t nearly as complex as aircraft are, and there’s a fairly known set of issues that can occur with them, so you can conduct a rigorous analysis like this using available tools (and a little imagination), and can pretty much figure out all the worst case scenarios within a day or two; a week tops. You also don’t have to do this before you get approved to build your project, as that is driven by FAA regulatory requirements meant to enhance the success of new aerospace projects (even though it creates a lot of overhead to the design phase).

Which brings me to my next point…

Well, not really.

Or, I guess I should say that the steps you take along the way don’t necessarily have to all work out of the gate. It’s the final product that counts.

A good practice when designing a new complex system is to identify the things that are novel, and then identify things where a pretty common approach or the solution already exists. Once you’ve done that, you can minimize the set of things that you need to experiment with first before you’re ready to combine it all together for the final product (which if you’ve done your experiments well should indeed work pretty well).

In aerospace, there is a tool called TRL (or Technology Readiness Level) which is a very cool framework invented by NASA that attempts to classify the maturity of technologies, classifying their progress from ideation, to simulation, to lab testing, to first flight, to heavy use in production. The idea is that if you can classify the TRL of all the major components of your system, then you can identify which parts are indeed novel (meaning there doesn’t exist a mature option you can use) and which parts you can find alternatives for that work well enough for your intended use cases. By doing this, you can increase the aggregate maturity of your project, and give it the best chance for success, since you’ve minimized the amount of “new things” you are working with that require enhanced verification work before launch.

This is a good skill to learn, many engineers at the highest level get pretty good at researching and identifying pieces of technology that meet the needs of the project, and reduces the amount of new code that needs to be created. In Crypto, this is a necessary skill because creating new code has a much higher barrier to cross in order to “qualify” it for production (testing, audits, etc.). Basically, reuse what you can and focus your innovation on what is truly innovative.

But most of all, the only really true test of secure software is simply how much exposure it has had in production, basically a crude calculation of how much time it’s been in that environment, at intended levels of use (the more the better), as well as the range of use cases that it has successfully solved without failure. Software components with a high “TRL” score very highly in all of those dimensions.

Let’s take a practical example, say you’re designing a new bridging protocol. You want to make an innovative cross-chain asset transfer system by having mirror tokens on other networks. To do this, we also need to establish a trading market for those tokens to retain their relative worth. Well, part of that system actually already exists, since we can use Uniswap’s AMM (which is deployed on multiple chains) to ensure that bridged assets retain close parity with their own copies on their originating chain. It makes no sense for us to reinvent the wheel here, this project already works quite well in production, and it’s not the core innovative component we are developing.

Since we’re using an established, mature component for that part of the project, that means we can focus more on the innovative and difficult parts, which makes the overall project much more likely to be successful. And that’s great because…

The last point in the tweet about having a “[limited] number of shots to achieved PMF” (product market fit, for those who don’t speak VC) is definitely very true. But it’s also predicated on a lie.

Let me explain.

The lie is that you need to achieve PMF almost immediately, since the amount of time it takes to “qualify” your software for production is so high, it really limits the amount of times you can spend rebuilding everything from scratch.

Wait, why are we rebuilding things from scratch?

We covered this in the previous section (kinda), but if we’ve done a good job at reducing the number of truly novel ideas we are trying to explore, we should set ourselves up for success because we don’t actually have to rebuild everything from scratch, just the parts that didn’t work as we expected.

You see, the best way to be successful in building complex systems is breaking them down into smaller, self-contained components that can be independently iterated upon and tested before being combined into the larger application.

This is the part that is probably hardest though, because the ability to truly “test” novel smart contract mechanisms is pretty hard, mostly because the “complex” part of the system happens to be the Cryptoeconomic schemes we are all trying to play with. We don’t truly know how to simulate and test those (outside of simple modeling), so our only choice is to “test in prod” (aka experiment on live, willing degens) once we’ve reached the limit of what local testing and simulation can show us.

So, there’s nothing we can do?

Well, we can take another page out of the aerospace handbook and follow a tiered approach to testing and release to de-risk the likelihood of failure at each step (as well as increasing our chances of hitting PMF, if done correctly). Actually, one of the reasons that we created the cHaOSneT ephemeral testnet product was that we think there’s a gap between local testing and production which needs to be filled by a full system-in-the-loop integration testing platform, and which can also be used to run full-stack simulations of our components, pre-launch “public” testnets for our userbase, and continuous “fire drills” (post-launch) for the team maintaining the project in a controlled environment, with limited impact for project teams and their users. The nearest analogue we have in aerospace is creating Ground Test and Flight Test procedures.

Typically, when aerospace projects get pretty far along in their development processes, they go through Ground Test procedures that are designed as a way to validate that all these larger components actually work. It’s called “Ground Testing” because we can test them in a controlled environment where things are bolted down and secured to the ground. A great example of this is rocket “hot fire” tests, which is basically just a way to see that the (extremely complicated) rocket engines actually do their job.

https://www.youtube.com/watch?v=zi8RJlx6Eo4

For Crypto, what we can do to simulate a “Ground Test” of some component is performing larger-scale, agent-based simulations demonstrating that across a variety of different environments that the component functions as intended. A great example of a project doing this in practice is DelV’s (formally ElementFi’s) simulation framework for the next iteration of their protocol:

https://github.com/delvtech/elf-simulations

Anyways, Ground Tests validate that as the project comes together, all the largest pieces are working as intended, which is really convenient to de-risk probably the scariest part of any aerospace project development: Flight Testing.

Flight Testing is scary because no matter how much simulation and testing we’ve done, there’s still no way to know for sure that it’s all going to work together. This is because often the full system simply isn’t capable of being tested in a controlled environment or in a truly “safe” way. The best we can do is try to limit the scope and envelope of our test flights so that we are achieving the key objectives we need to prove that the system is fully capable of the mission we designed it for.

Still, the worst case scenarios often happen, but we prepared for them since we knew from the start what the worst outcomes could be, and we have backups and contingencies for the failures that are possible (since we already did our analysis). This is the best way we can make sure our project pushes the envelope of what’s possible in the safest way we can, so scenarios like a rocket blowing up aren’t catastrophic to the project:

https://www.youtube.com/watch?v=w0ZlFXoq4c0

For a Crypto project, what we can do is run a Beta launch or some sort of incentivized testnet, meant to uncover bugs, inefficiencies, and places where we misunderstood the problems we expected the project to face during the design phase. A good team will have designed out a roadmap of these tests all driving towards the final stage of the build process: actually launching the damn thing for everyone to use!

I hope some of my insights from my prior career is helpful to you when thinking about how you can best design and build safe, secure, and successful projects that work well. I want to thank @danielvf and @0x_Osprey for reviewing this article and giving great feedback.

For the latest on all things Ape follow us on: apeworx.io | Discord | Twitter | Bluesky

Code Coverage is a simple and (for some reason) controversial topic. Ask any group of developers, and you’re likely to get many conflicting opinions on how to do it properly. Some will say “well 100% or bust”, others will say it doesn’t matter at all. Some absolute crackpot (totally not me) may come at you with a line like “well actually, there’s between 7-13 different types of coverage, depending on how you measure it”, and what’s wild is that they would all be right. And also all are wrong. Each tell a version of the truth, because coverage is simultaneously a really important and powerful tool for increasing the safety and quality of code, as well as an absolutely useless measure of code safety and quality.

Confused? Good! Now let’s begin our journey!

p.s. this is Part 1 of our series on understanding code coverage. This piece will be an overview, while Part 2 will be practical using Ape Framework’s new coverage feature. But more on that later.

“Code coverage* is defined as a percentage measure of the degree to which the source code of a program is executed when a particular test suite is run.”* - Wikipedia.

Uh, thanks Wikipedia. Very helpful.

So what does that mean? It means that when you create a test, there are particular areas of the code you're trying to verify that you are activating when you run it. It’s usually measured on a percentage basis, meaning if you have covered 80% of the entire source code then 80% has been activated while testing. Getting to 100% means you are activating the entire code in some way by running your tests. Is it the right way? Who knows, all it tells you is you got 100%. A perfect score. That’s all we care about. Our work is done. We are totally safe now.....

Right?

Annoyingly, the answer is no.

Code coverage metrics, as a percentage score, are really telling you very little about whether your code doing is the right thing, which is what we care about at the end of the day. The only thing that 80% coverage means is that 80% of the code did something during the test, not if it's what you wanted it to do or if it was done well.

To makes things even more confusing, most people only ever talk about "statement coverage", which is just one of many types we can use (don't worry we'll get into them later).

Code coverage is imperfect, but useful and should be combined with other tests, fuzzing, and old-fashioned eyes-on-the-code to work through if your program is actually doing what you want it to. And whatever you do, always keep Goodhart's Law in mind:

“When a measure becomes a target, it ceases to be a good measure.” - C. Goodhart

Now, as the totally rational, sane person quoted in the beginning said (that’s totally not me), there are actually many different types of coverage we can use, so lets look into the the differences and what the shortcomings of each:

Fundamentally, a particular coverage metric such as statement coverage measures the hit rate (aka the number of times a particular statement is hit) of a particular type of structure present in our code, such as a single statement in source code. 

A statement is computer science jargon for an element of your program that expresses a complete “thought”, but just to keep things simple we are just going to think of it as a single line of source code.

Allow me to present a Python program as an example:

1 def function1(value: int) -> int: 2 3 if value == 0: 4 value = 1 5 6 return value

This is a pretty simple program, but what happens if I told you that you could get 100% statement coverage with just one test? That’s pretty efficient right?

As I hope you can see, if we make the call with value = 0, we will actually be able to achieve 100% coverage of this code, since we will hit the if statement on line 3, the assignment statement on line 4, and the return statement on line 6. Of course, we’re calling function1 so we will count that, and also we really don’t care about the whitespace on lines 2 and 5 (because they’re not actually programmatic statements).

That’s great! But what are we missing? Well, we begin to see how 100% statement coverage might not be telling the whole story. Looking at the if statement on line 3 gives a clue: what if this condition were false? The statement coverage metric is that line 3 is just hit, it doesn’t specify anything about how it was hit. That concept is actually a different form of coverage called branch coverage (sometimes called edge coverage). Branch coverage checks that when we hit a statement that can cause a branching point in your code (literally a point where it has a binary choice to proceed down one path or another) that we trigger both the positive and negative scenario of this condition (e.g. value == 0 and value != 0). Going back to our program, we only have one branch condition to measure, and we’ve only taken one of the branches in our test case of calling with value = 0, so this means we’ve only achieved 50% coverage of our branch conditions. Adding another test case where we call with value = 1 will be enough to satisfy the other prong of that branch point by not triggering the condition, which will skip the if statement and proceed right to line 6.

Alright, let’s talk about a slightly more complicated example:

1 def function2(value: int) -> int: 2 3 if value == 0 or value > 10: 4 value = 1 5 6 return value

This time by executing both value = 0 and value = 1 test cases, we are able to achieve 100% statement coverage as well as 100% branch coverage too. However, I’m sure you’re able to see that the additional logic on our if statement might be cause for concern. But how? We have 100% coverage!

Of course, the solution to any problem in computer science is that if your initial idea doesn’t work out, just add more abstraction. Clearly just checking that we proceeded down both paths of the branching if statement is not enough to fully exercise the logic of the condition inside of it. This may or may not be important to you depending on your needs, and indeed many coverage tools conveniently stop at statement and branch coverage.

But consider this: what if our understanding of function2 was that it was supposed to be functionally identical to function1? By only checking our two test cases value = 0 and value = 1, we would see that is indeed the case since they produce the same output. They would also produce the same output for value up to 10, and actually below 0 as well. But if we pass in value = 11 all of a sudden the two functions will return different values.

That isn’t good. But how do we detect this with coverage?

Good question. First, let’s talk about the condition in our if statement. The condition is a compound expression involving and. In function1 further above, we only had the expression value == 0 to evaluate both true and false to achieve full branch coverage. Now we have two expressions: value == 0 and value > 10. With our two test cases we’ve made both expressions true at the same time, but we’ve only evaluated the first expression false once, and have never made the second expression change value to false. For the purposes of computing branch coverage, this is enough, since if one of the expressions of an and expression evaluates false, then the whole expression evaluates false. But if instead we look at a metric called condition coverage we need to look a little deeper into the branch statement and determine if it contains a compound expression, and if it is a compound expression we need to check that we’ve achieved the positive and negative cases for all of the sub-expressions. Before adding our value = 11 test case, we would have had only 75% coverage of the and compound expression (positive and negative for value == 0 but only positive for value > 10).

Now we will have 100% coverage across 3 coverage metrics!

Of course branch, statement and condition coverage are only 3 examples of coverage that produce useful checks to ensure you’ve explored as many paths in your program as possible. There are other types of coverage to check for, but they can have diminishing returns vs. the amount of time you spend achieving 100% coverage on them. What’s more important is that you’ve exercised your code under both the anticipated scenarios that you expect your users to use, as well as all of the edge cases and failure modes that you want to protect your code against.

A good suggestion would be to design a test suite that covers all of the anticipated scenarios for your users that you want the code to function for, as well as checks the failure modes and edge cases that you don’t want the code to handle (by failing gracefully). Once you’ve done that, the next step would be to measure the coverage of this test suite and see where the gaps are. Those gaps are the key, because they show you places in your codebase where you are missing something: missing a test (perhaps not understanding a requirement or under-specification in your design document… you do have one, right anon?), or you made the code too complex (such that it has more edge cases than you expected), or otherwise made a mistake somewhere along the way.

But I promised to tell you more about other types of coverage, so here is a list (again, thanks Wikipedia for the categories):

• Function coverage - higher level, but basically have you called every function possible

• Modified Condition/Decision Coverage (MC/DC) - you’ve checked each sub-expression in a compound branching point individually e.g. if (a or b) and c)

• Parameter Value Coverage - you’ve checked all possible input types that the function might be called with in practice (great use case for fuzzing since this is usually pretty hard)

• Linear Code Sequence and Jump coverage - not only every if statement in your source code, but every type of branch condition that the final executable supports (for example in EVM programs, have you called the fallback method? triggered empty value checks? external call failures? etc.)

• Path coverage - have you covered every possible path in the final executable? (often fairly low level for common usage, albeit more exhaustive)

• Entry/Exit coverage - have you entered into every possible function and triggered every possible return statement in that function?

• Loop coverage - have you checked all loops if it is possible to break early, or skip iteration entirely, as well as execute the full loop iterations without hitting the break condition, if one exists?

• State coverage - have you explored all possible states that the program can take (in EVM programs often this isn’t possible without some form of Symbolic Execution, which is an exhaustive search of all possible states)

• Data-flow coverage - has every variable been initialized and used?

Now that we understand pretty well the taxonomy of different types of coverage criteria and how they work, it’s important to know how one measures coverage in practice. You might be thinking “why do I care?” but it’s important to understand this, as some ways of collecting coverage information actually change your program!

Whoa there! That’s not cool! If the tool modifies my program, isn’t there danger that it could make it not match the production behavior?

Yes! That is a risk you are taking!

You see, some coverage tools will modify the program you are measuring coverage for by inserting variables in particular points in the program that check to see if they are hit or not. Usually these values don’t affect the execution of your program, but they can slow it down and have other performance effects. In EVM programs, where the execution cost of a program is actually one of the critical resources that gets tracked (e.g. gas), then even adding harmless variables incurs extra resource usage that could modify the state of the program, e.g. make it fail when it should be passing. Therefore, for measuring the coverage of EVM programs, it is recommended not to use these approaches as they will impact the correctness of the results.

Other tools, like Ape’s new coverage feature, will instead take execution traces and post-process this data into the relevant coverage metrics (fortunately for EVM programs, this is a relatively easy thing to do).

In our next post, we’ll walk through in more detail how to use Ape’s coverage feature effectively when preparing your EVM-based contracts for production deployment.

For now though, I hope you found this article useful in understanding exactly what coverage is and how it works!

For the latest on all things Ape follow us on: apeworx.io | Discord | Twitter | Bluesky

subscribe://

A Platform for Web3 Bots

The decentralized web is inexhaustibly and unrelentingly connected. It was designed to provide an open architecture to build the next iteration of the internet, one that was more permanent, more accessible, and less discriminatory to its users. It has no concept of nationality, race, ethnicity, sex, class, gender, age, or political correctness. Hell, it has no concept of a “bedtime”.

At the core of this hyper-connected, decentralized new world are high-value full-stack applications, which use smart contracts at their core to enact self-executing rules and policies that guide complex economic decision-making outside of the blockchain’s sand-boxed execution environment. But smart contracts aren’t where we live. We live in the real world, and in the real world, we want things like nice interfaces that display up-to-date, relevant information. We want reliable automation for tasks we don’t have the time to watch or handle. We want to build rich, sophisticated applications leveraging these policies at the core to drive an entire ecosystem of economic behaviors.

We want to build great products.

We recently launched cHaOSneT, our testnet-as-a-service (with a twist):

https://mirror.xyz/apeworx.eth/mIKYEt54RgNs7R12Np1vEyp8z5HuBKBdCjCWqrnNfe8

As with all great products, we needed great infrastructure to support it. This infrastructure would need to be robust in times of stress, safe from exogenous and indigenous security threats, and have a set of finely crafted rules that it would follow when you’re not there to guide it out of harm’s way.

Silverback is a fundamental part of what makes this product great, because it allows us to support deployments of large amounts of automated behavior which makes our chaosnets feel just like the real mainnet environment. It allows us to quickly and easily provision, monitor, and manage our deployments so we spend less time on maintenance and more time delivering new and innovative bots that automate the types of behavior our users want to see.

Without Silverback, we wouldn’t be able to scale up cHaOSneT to a world-class product. But what are the specific things it solves to make our engineers’ lives easier?

We aren’t all experts at infrastructure management or operations. Most of us want something that Just Works and don’t want to think about what’s running underneath. Containers? Message queues? Archive nodes? Websockets? I just want to write a simple script!

Here’s a Silverback bot that handles $USDC Transfer events:

from ape_tokens import tokens from silverback import SilverBackApp app = SilverBackApp() USDC = tokens["USDC"] @app.on_(USDC.Transfer) def exec_event1(log): # Do something with `log.amount` ...

How simple is that? There’s no worrying about what node we’re running on, if we’re about to run out of API credits soon, what happens if we have an error in our code sometimes? It. Just. Works.

The secret to operating anything important at scale is to protect yourself from… yourself. Nowhere else in Crypto is this any more evident than private key management. You cannot go a single week without learning about how someone got hacked and lost their private key. Basically, it’s not something you want to fuck up.

Thanks to Ape’s extensible plugin architecture, we can provide a seamless experience for your bots using managed key infrastructure that’s way more solid and battle-tested than what most people would develop themselves. It also allows us to support many more advanced types of managed key services, that will be released alongside the full Silverback platform release. You no longer have to worry about your private keys leaking as these secrets will be encrypted at rest, and only accessible via dedicated account plugins that the platform provides.

And besides that, we’ve made it so damn easy to use:

from ape import chain, project from silverback import SilverBackApp app = SilverBackApp() @app.on_(chain.blocks) def exec_event1(block): # Deploy a `Token` contract every 1,000th block if block.number % 1000 == 0: app.signer.deploy(project.Token)

That was a major goal with the product, to make it as easy as possible to do the safe thing well, so it can be a product you can trust with 5, 6, 7 figures… or more.

It can be really stressful to trust so much with a robot. But what choice do you have? You have to sleep sometime, and the chain never sleeps. Thankfully, Silverback’s risk management engine is there for you.

Perhaps the most important thing when creating truly trustworthy automation is that you can trust it to follow the guardrails you give it when things don’t go the way you want them to. Silverback bots will generate a set of metrics that can be externally monitored for deviations which should trigger a shutdown of your bot, as well as let you define your own programmatic logic which should stop processing immediately and trigger your shutdown procedures:

from ape import chain from ape_tokens import tokens from silverback import SilverBackApp app = SilverBackApp() USDC = tokens["USDC"] INITIAL_BALANCE = USDC.balanceOf(app.signer) @app.on_(chain.blocks) def exec_event1(block): ... if USDC.balanceOf(app.signer) < INITIAL_BALANCE: # Trigger a shutdown, and raise an alarm raise CircuitBreaker("We've lost too much money!")

Also, through the Silverback platform’s metrics and logging features, you will be able to monitor the performance of your bot in order to identify longer-term trends like gas usage, transaction failure rate, and more.

You might be thinking “This all sounds great, how can I sign up?” and unfortunately we are only at the beginning stages of this journey. Silverback is a very innovative platform, and cHaOSneT is the first large-scale use of that platform, so we are still finding a ton of things about how it works and what types of features it will need to be most useful for production use cases. Thankfully, chaosnets are a fairly low-risk way for us to identify any problems with this architecture in the short term, and will ironically be a great test bed for back-testing your own production bots before they’re ready for prime-time on mainnet.

However, that’s not to say we don’t have something for you today. Our community was extremely excited to learn more about how they can build their own bots, so we wanted to speed up the timeline of releasing our open source bot-building library and SDK for the Silverback platform. You can check it out here:

https://github.com/ApeWorX/silverback

You can use the library today for building a bot and run it using silverback run against any network, yes even production (you degen you). But to take advantage of the full power of the Silverback platform, you will have to wait a few more months until we release more details on the design and features that the platform will launch with.

For now… good luck and good hunting.

- ApeWorX

For the latest on all things Ape follow us on: apeworx.io | Discord | Twitter | Bluesky

Streaming Crypto Payments for Off-chain Services

What’s this? Yet another streaming payments system?

Yes, but we swear there’s a good reason we built and open sourced a new one!

When building cHaOSneT we realized that we had a decision to make: did we want to go the Web 2.0 way and use traditional login and payment processing, or did we want to go full Crypto-native and try to build something new?

https://mirror.xyz/apeworx.eth/mIKYEt54RgNs7R12Np1vEyp8z5HuBKBdCjCWqrnNfe8

Of course, we decided to do the latter, but this meant researching Crypto-native login and payment solutions. Login was easy, we used Sign-in with Ethereum, but in researching streaming payments platforms we had some problems. All the options we researched either didn’t have the right UX for this use case, were upgradeable (which is poor for automated services as it could cause an outage… among other things), or were otherwise not making updates to the protocol anymore. So… we needed to build our own!

ApePay is designed from the ground up for the needs of automated service provisioning performed off-chain, such as the types of services we are building at ApeWorX for our users. We needed a minimal payment protocol that was flexible enough to meet our needs, and yet safe for users by allowing them to withdraw at any time to stop using our services. An upgradeable protocol was immediately off-limits. Maybe it would have been useful but it’s just not safe, and we also wanted to open source this protocol, so allowing what might seem like a minor upgrade to the contracts could risk completely wrecking our infrastructure. Immutable protocols are the way to go for robust, scalable infrastructure since their behaviors won’t change on a whim.

That’s great, but here are some of the actual benefits of ApePay’s architecture:

1. It’s extremely scalable!

2. it unlocks smart contract workflows for users

3. It can re-purposed for multiple different products

We also added support for Permit2, and wrote it in gas-efficient Vyper v0.3.9!

But let’s dive a little deeper…

Since ApePay is a decentralized application, and not just another centralized payment service, downtime is effectively eliminated. We don’t have to host servers, or make relationships with credit card companies in 195 different global jurisdictions. Everything is just crypto, streamed at a defined rate, until it either runs out or is cancelled by the stream creator (or us).

Reliability makes it possible for us to build our product infrastructure around this protocol, and that’s exactly what we’re doing by leveraging the upcoming Silverback platform for managing the off-chain integrations behind each of our products. When you open an ApePay stream, our infrastructure will automatically detect this action, and then parse the stream to provide the services that you paid for, as transparently and quickly as possible.

What about spam? Chargebacks? Compliance?

Since each ApePay StreamManager contract is it’s own self-sovereign hub, the owner has complete control over how they handle streams and under what conditions users are allowed to set them up in the first place. By using an optimistic architecture - basically that you trust the hub owner enough to open a stream with them - we can eliminate a lot of the complexity of negotiating on-chain when errors do happen. Made a payment by mistake? Close the stream (after a pre-defined warm-up period design to protect against DDoS attacks against the infrastructure). The service was down? The owner can just credit you with more time than the stream specifies off-chain. Only want to allow certain users during a limited beta? Add validators contract to deny users who shouldn’t be allowed or don’t meet specific conditions.

All of these features are executed completely on-chain, and we can rely on this behavior to negotiate off-chain using the assumptions of the protocol. Very human, and easy to use!

This was a cool one for us to realize, imagine this: what if you allowed a service user to be a smart contract that pays for it’s own usage? As an example, let’s say you are building an arbitrage bot that runs on the (upcoming) Silverback platform. You create a contract used to hold the assets at rest, and have that contract manage it’s own payment stream used to pay for running the bot directly from the profits! This is really cool, because you don’t have to worry about setting up those recurring payments, or what happens if your payment processor goes down, since it’s a decentralized application that’s always running the subscription as long as you want it to. What’s more, you can have the bot shut itself down if it’s no longer working profitably.

This is the future we’re asking for!

If we were gonna design our own payments protocol, we wanted to make sure it was flexible enough to support all our future products. Since ApePay is a very simple but very configurable system, we were confident that it can grow and scale to support whatever future products we (and the community!) might build with it. And by open sourcing it to our community, it’ll be interesting to see how others might evolve and adapt the rules of the protocol to create even more interesting use cases.

It’ll be especially interesting to see how ApePay will allow centrally viewing and managing payment streams across our product suite, and potentially from multiple service providers, all from a convenient dashboard (coming soon™)

ApePay is being open-sourced under this repository, and maintained by ApeWorX. We accept feedback, contributions and feature requests, and will be integrating it with our cHaOSneT product shortly. For now, there is no public deployment, but will be coming shortly, and of course anyone can deploy their own for testing purposes.

https://github.com/ApeWorX/ApePay

If you want to be one of the first to try out cHaOSneT just sign up to our Mirror email notifications to be given front row access for when we launch the Beta! Just sign up above and you’re in!

#PrepareForcHaOS

- ApeWorX

For the latest on all things Ape follow us on: apeworx.io | Discord | Twitter | Bluesky

We’re proud to release our latest product into a private alpha: ChaosNet

Fork any chain, at any time, and create virtual humans to interact with it as if the chain was alive.

ChaosNet changes the way testnets work by giving you 100% real....fake people to let you see exactly how real people will interact with your project.

The Three Core Powers of the Chaosnet AI:

• Replicants: Create Autonomous Actors who mimic human and non-human behaviour. Turn on developer God-Mode to see how people would actually use your project.

• Time-Travel: Select any block to go back in time and see what would happen if things went differently using the behaviour of the people who were there. Speed up, slow down, or view any chain activity and see whats happening as it happens.

• Simulacrum: Replicate events from other chains and simulate anything from USDC depegging, to Satoshi coming back, to a chain collapsing and see it play out in real time. Watch as a chain collapses, a fork splits, or a bridge is hacked without you getting rekt in the process.

Simulate events, strategies, the past, the future, and users with the AI power of ChaosNet

If you want to be one of the first to try out ChaosNet just sign up to our Mirror email notifications to be given front row access for when we launch the ChaosNet Beta! Just sign up and you’re in!

#PrepareForCHaOS

- ApeWorX

For the latest on ChaosNet follow us on: Apeworx.io | Discord | Twitter | Bluesky