IRIS hardfork – the long anticipated protocol improvements
Almost a year and a half has passed since the
lima hardfork. The time has come to upgrade the protocol with
iris. This is the first potential hard fork after the three
initially scheduled ones and thus it requires a community vote. In the following
sections we will go through the improvements that iris brings. There is no big,
new functionality, but rather a lot of significant improvements and bug fixes for
the existing ones. The biggest changes are in the realm of smart contracts but
there are also some positive changes in every part of the protocol.
As there has been mention of it in the public channels, it is worth mentioning that
iris is not a HyperChain release.
lima introduced the Fast Aetenity Transaction Engine (
FATE) which made contracts more efficient both in terms of computations required to run a contract and of the memory footprint of a contract. Ever since, we’ve been growing our knowledge base, doing R&D on how we can further improve it. This is how
FATE VM v2 was born. It brings a lot of enhancements under the hood but what users will actually notice are the new primitives:
Native BLS12-381 crypto pairing operations. At last there will be Zero-Knowledge (
ZK) proofs on Æternity. This could benefit both on-chain and offchain contract calls and it is a great addition to the arsenal of tools Æ already has.
AENS has been revised and certain opcodes have been added:
AENS.update(now you can update name pointers from a contract) and
AENS.lookup(now you can inspect existing names in a contract). This will improve further the usability of names. There are some bug fixes there:
AENS.resolveused to crash on an invalid name and the TTL of preclaim transactions was always set to 0, disregarding the value provided.
Oracles has been improved with a new primop:
Oracle.expiryso a contract can inspect when an oracle expires on-chain.
Chain.block_hash(Chain.block_height)used to always return
None. Now it returns whatever is the current generation’s key block hash.
Transaction introspection in generalized accounts via
Auth.tx- generalized accounts now can perform deep inspection of the transaction to be authenticated. Dry-run endpoints can optionally access
The string operations have been revisited as well: there are some new ones -
Char.to_lower/upperwhich can help with conversion of data. The
String.lengthnow returns the length of
to_liston the string instead of its
byte_size, which feels much more natural from a user’s perspective.
Adds a new named argument “
protected : bool” to remote contract calls. A remote call with
protected = truegets its result wrapped in an option type, with failing calls returning
None. When the protected call fails then any side effects from executing the protected call are rolled back.
The persisted on-chain bytecode now includes the compiler version.
One of the improvements under the hood is that the
FATE VM v2garbage collector had been reworked - from
irissome operations are much cheaper, especially nested maps.
The persisted on-chain bytecode now includes the
initfunction is not callable after deployment but can be used to clone an existing contract.
Contract factories - Solidity-style contract creation capabilities come to Sophia. The factories bring a lot of improvements with regards to user experience, for example DeFi services on Æ can now be wrapped in a single transaction. This is something we’ve discussed a lot and due to popular demand, will be included in
Contract cloning: cheap and reusable clones of existing on-chain contracts.
Contract bytecode introspection - contracts now can query the code hash of existing
FATEcontracts - further improving UX and improving the security of Æ based DEFI services.
Currently in order to include transactions, one must have a balance to start with,
as at least some fees are required for a transaction.
iris brings the functionality
to wrap your transaction in a special new
paying_for transaction. This allows a new entity for the transaction - so called
payer - to cover the fees and the gas cost on behalf of the
origin. Note that any amount spent by the
origin still will be deducted from their account and not the
payer's. Still, this allows onboarding
users without existing accounts for various business cases.
aens support has been around ever since the
roma release but has undergone a few iterations and improvements during its lifespan. The latest ones originate from the community. For example the name expiration time was a pain point for users all along. It used to be 50000 generations (~100 days) which means in order for your names not to expire - you must update them more than 3 times a year. Since names are intended to act like DNS on the blockchain, this feels unnatural and leads to bad UX and expired names. There was an on-chain vote in order to let the community decide what would be better. The community spoke and name expirations were changed accordingly to 180000 generations (~375 days). Another improvement regarding names is the restriction of AENS name pointers.The goal of names is to provide shortcuts to certain addresses and some of those are predefined (like
oracle_pubkey) but there is also support for users to create their own. Since now the network is maturing we propose certain restrictions so the
aens is more finely tuned, ex: no duplicate pointer keys are allowed anymore, a maximum number of pointers is enforced per name and now there is a certain restriction on key length.
Generalized accounts allow for newer and greater authentication methods, better
fitting the specific use case of the user. This is further improved with the ZK proof
FATE VM v2. The changes to GA here in
iris are incremental and simply polish: the pricing model is improved and the TTL handling of transactions is more finely tuned.
AEVM was the initial smart contract VM. It was based on the
EVM (Ethereum Virtual
Machine) but since now we have the much more efficient
FATE VM, it is rendered
obsolete. For some time now it has only imposed a technical debt while it brings
absolutely no added value. We deprecate it from
iris on. This will allow us to add
State channels provide means for virtually unlimited transaction throughput by
moving those transactions off-chain. They rely on participants being online, protecting their own interest. This assumption is not always a practical one and
that is why we have delegates: a third party that can provide off-chain state onchain in order to protect the interest of a participant. We have revisited delegates and completely reworked them. From
iris on, delegates are per participant. They can not only provide
slash transactions but if needed they can also provide a
snapshot. If the channel is already closing and a participant has enough stake in a contract, a delegate can even do a
force_progress on their behalf. This all makes delegates a much more useful and powerful tool for keeping participants safe offchain. So far the list of delegates was immutable: one could not change them after the channel had been created which is particularly bad for long running state channels. From
iris on there is a new transaction type -
set_delegates that allows participants to modify the list of delegates while the channel is running.
We have identified an odd bug in
force_progress: if a participant calls a contract offchain and this call fails, the
amount in the call is still locked in the contract. This behaviour is even more odd when the function called is not
payable. This off-chain propagated on-chain via
force_progress transaction. All of this is fixed in
Oracles provide data from the physical world on-chain. So far one had to query an
oracle using its address, but
iris brings the functionality of named oracles as well: if there is an
aens record for that name and it has a set pointer for key
oracle_pubkey - one will be able to use the name handle in their query transactions.