Smart Contracts/AVM FAQ

What is a smart contract?

At the level of cryptocurrencies, a smart contract is a computer program that is stored on a blockchain and specifies contractual terms, along with possessing the means to enforce those terms.

For more information, please see the following:

What is the AVM?

From the Solidity Introduction to Aspire Smart Contracts:

“The Aspire Virtual Machine or AVM is the runtime environment for smart contracts in Ethereum. It is not only sandboxed but actually completely isolated, which means that code running inside the EVM has no access to network, filesystem or other processes. Smart contracts even have limited access to other smart contracts.”

The AVM is not a virtual machine like VMWare, instead it is a protected sandbox for smart contract execution.

Can Ethereum or Counterparty smart contracts run on Aspire?

Yes. Aspire supports the same smart contract functionality that Ethereum does. There are a few minor tweaks (e.g. hardcoded addresses needing to change) but any Solidity or Serpent smart contract used on Ethereum or Counterparty should be able to work on Aspire with very little modification.


What languages can I use to write a smart contract?

Aspire will support smart contract code written in Solidity or Serpent .

How does it work at a high level?

  • You write the smart contract code (using Solidity or Serpent) and compile it to a more compact form (bytecode).
  • Aspire will create and broadcast a publish transaction to embed this contract code into the gAsp blockchain. This is done in a way that is spendable and doesn’t “pollute” the blockchain.
  • Once published, the smart contract “lives” at an address, which looks like a regular gAsp address, but starts with an C.
  • You can then use Aspire to create and broadcast an execute transaction to call a specific function or method in the smart contract code.
  • Once an execution transaction is broadcast and confirmed by a gASp miner, every running gAsp node will receive this request, and execute that method. As the smart contract code executes, it modifies the contract state, which is stored in the Aspire database. Since each gAsp node has the same contract code as well as the same AVM code, and the code is all deterministic, these state changes are the same for every node.
  • Others can also send Aspire assets to the smart contract, which will store them and can use them in future execute calls. This is useful for things like funding contracts, for instance.
  • Essentially, we see that the publishing of smart contracts and the command to kick off the execution of a specific function or method in a contract are made as actual transactions on the gAsp blockchain. Thus, these two operations are limited by gAsp’s ~2 minute blocktimes. However, once an execution of smart contract code is kicked off, it generally runs as fast as the node can process it.

When will Aspire be released on the gAsp mainnet?

Basically, “When It Is Ready” (TM). A lot of it depends on how good of a job the community can do testing the AVM code on testnet. Nonetheless, we have an agressive time schedule (within the guidance of prudent safety measures), and an interest to release as soon as we deem it ready. Realistically, we expect sometime in Autumn 2019 for the mainnet release.

Can I use an Aspire asset in a smart contract?

Yes, smart contracts may hold and control any Aspire asset, such as ASP, LMY, and any others to come.

Why wouldn’t you just create smart contracts on Bitcoin instead?

Counterparty was launched to use Bitcoin’s blockchain as the backbone of their platform. At times Bitcoin’s expensive fees and slow block times have left sending Counterparty assets too slow and fee expensive to be useful. Solving this problem is one of the main reasons Aspire was created. Like Counterparty, Aspire can interact with any Aspire asset, however they cannot control or send Bitcoin.

What is used as Gas?

gAsp is “burned” (destroyed) when smart contracts are executed, to essentially pay the network for their execution.

Won’t that cause deflation of the gAsp supply?

Yes, and unlike ETH, the supply of gAsp is fixed. However, this should not endanger the network itself: for a given smart contract execution, the amount of XCP consumed will slowly decrease as the supply in existence shrinks. This will ensure that the amount of XCP never goes to zero.

How does gAsp’s 2 minute block time affect the AVM?

After a contract is written, it is “published” to the blockchain, which embeds its data in the blockchain, ensuring that all gAsp nodes have the same contract code to execute. Once published, a method/function on a contract may then be executed.

Both the publishing operation, as well as any execution operations, are published as a Aspire transaction (inside a gAsp transaction) and thus subject to the block time. However, once a contract executes, it will move from line of code to line of code as quickly as the host computer allows, and individual “steps” within a contract are not subject to block times. Nor is a contract executing another contract (via CALL) subject to the block times, and the called contract method (as well as any methods that it calls, and so on) execute immediately.

Thus, the block time limit is overall rather minor, and only affects the initial publishing and the initial execution of a contract method.

Can payment channels be used with the AVM?

Not currently. With the AVM, when a contract’s “state” (i.e. storage data) is modified via an execution operation, all gAsp nodes on the Aspire network must perform the operation at the same time. This is because all contract state must be identical and shared across all nodes.

Payment channels, on the other hand, are essentially a private negotiation between two parties, who, once they agree, will finalize their agreement on the blockchain. This is done via utilizing gAsp’s internal scripting language in a certain clever way (i.e. intentional non-broadcast double-spends). The AVM, on the other hand, relies on all nodes updating their state as a contract runs (i.e. no “private negotiations”) and does not utilize gAsp script directly. Instead, all AVM operations are embedded inside Counterparty protocol data.

So while, technically, the parties could “negotiate” an AVM publish or execute operation, it would not yet be broadcast, and thus, not have any impact on the AVM’s global contract state.

This all being said, there are certain use cases where payment channels could possibly be used for AVM interactions: Two parties may be able to negotiate an execution statement for a contract that only they interact with, and has no interactions or “side effects” to or from other contracts. In this case, they would essentially “pre-run” the contract execution, independently verifying the resulting state changes, and trading modifications of the original execution statement via payment channel mechanics. Once they were both happy with the results, they would commit the finial execution statement to the blockchain, where it would be actually executed, by the network as a whole.

The last bit is rather interesting and is a possible direction for future research and development.

How is this different than Rootstock?

    • The Aspire AVM will operate on gAsp mainnet, while Rootstock runs on a sidechain.
    • Aspire uses proven technology (i.e. embedded consensus tech proven previously via Counterparty) that has been in use for > 2.5 years on mainnet. Sidechains are very new and experimental.
    • Rootstock utilizes merged mining and federated pegs in their model. Both of these have a variety of possible issues with them.
    • On the positive side for Rootstock, their use of a sidechain (if successful) could lead to considerably higher transaction throughput than Bitcoin mainnet. However, if sidechains successfully work out, there’s no reason Aspire can’t adopt them as well, using the same embedded consensus approach as on mainnet, with much faster block times.

Why would an Ethereum developer develop on Aspire?

We don’t see this as an “either-or” type decision. With very little effort, Ethereum developers can port existing smart contracts to Aspire, and extend their reach to not just the Ethereum community, but the Aspire community as well.

I heard about The DAO hack. What was the problem?

The problem was not with a bug in the EVM (Ethereum Virtual Machine), but a problem in how “The DAO” smart contract (which was holding > $100 million at the time worth of ETH tokens) was written. Basically, the DAO was written to allow “splitting”, where one or several holders in a DAO can separate off into their own DAO fund if they don’t like the proposals that their current DAO is voting on (more info here). This splitting functionality was poorly designed and implemented and had numerous issues in the code. “The attacker” took advantage of these issues to award himself more ETH than he was entitled to, therefore draining the DAO of funds.

So to reiterate, the vulnerability that occurred is due to these bugs in the DAO smart contract, not a security bug in the EVM itself. (Although the Solidity language design can and most likely will be improved to make such smart contract coding mistakes less possible in the future.)

Are my Aspire assets at risk of any issue with a smart contract?

Not if you don’t send those funds to the smart contract (which allows it to control the funds via its code).

Unlike with Ethereum, where smart contracts are a fundamental and required component of most any action beyond sending Ether, our system is designed so that our core feature-set is completely independent of any smart contract functionality. This means that anyone can use Aspire’s well-tested asset creation, transfer and decentralized trading features without having to interact with or otherwise touch smart contracts.

What are the differences between the AVM and EVM?

They are virtual the same thing just running on different Blockchain’s

AVM is based on the newest version of the EVM software that is successfully running on Ethereum today and, we believe mature enough for use on Aspire/gAsp mainnet (with appropriate precautions)

  • Adds the ability for smart contracts to interact with Aspire assets
  • Includes the EVM Safeguard feature (see below)

How will the Counterparty team deal with bugs in specific smart contracts?

On Aspire, authors of smart contracts will be responsible for bugs in their contracts. In contrast to Ethereum, the Aspire Foundation Board, with development team guidance, has passed a “non-rollback” amendment to the Bylaws. This policy forbids the Aspire development team from publishing code to fork and/or roll-back the network as a response to bugs in specific smart contracts. Where the fault is due to a bug in the underlying AVM – and not any specific smart contract that runs on it – the development team will of course write and publish bug fixes.)

Can you walk me through the process to create a smart contract on Counterparty?

We have a “getting started guide” coming soon.

How do Smart Contracts “form a consensus” on Aspire?

Smart contracts don’t form consensus. Every network participant just executes each contract in the same way (like a ‘send’ transaction). The consensus is formed with the blockchain determining which contracts exist and the order they are found in. As each network node has the same smart contract code, as well as the same protocol (“consensus sensitive”) code, that operates on them, the output from the execution of each smart contract call will be the same (as all code that executes is deterministic in nature).

What is a simple smart contract that I, as a non programmer, can create with some simple copy pasting?

  • Ethereum has a “hello world” type tutorial here.
  • Here are some guides that discuss different use cases for smart contracts.