IRIS Hard Fork Release Process with Voting

Protocol Features & Updates Protocol Upgrades
, , , ,
1

The Iris Hard Fork (Release 6.0) previously scheduled for release on the 25th February, was postponed due to

• Allow state channels to dynamically add/remove delegates using Set Delegates transaction (scheduled for IRIS-rc1 or IRIS-rc2), is still in progress, along with some processes in FATE2:
• Fate1 ↔ Fate2 interoperability (scheduled for IRIS-rc1)
• Contract cloning, factories(scheduled for IRIS-rc2)
• Bytecode introspection in contracts(code_hash)(scheduled for IRISrc2).

A governance vote concerning the update to Release 6.0 will start on Monday, March 15th. If the vote outcome is positive, the scheduled date of release for the Iris Hard Fork (Release 6.0) is April 13th 2021, and node operators will have a time window to update their nodes. A positive vote outcome means that the majority of the voters have approved the iris release.

Done in FATE2
for details please consult the Sophia documentation
• Adds AENS.update - contracts deployed on FATE2 can update name pointers
• Adds Oracle.expiry - onchain FATE2 contracts can now query the TTL of an oracle
• Adds AENS.lookup - onchain FATE2 contracts can now inspect onchain names and retrieve the name owner, name TTL and all name pointers
• AENS.resolve will not crash on invalid names starting from FATE2 - FATE2 it will return “None” instead of crashing the VM
• Fixed bug regarding TTL of preclaims in FATE VM - it was incorrectly always set to 0, from FATE2 it has the correct value
• Changed Chain.block_hash - from FATE2 it will return
Some(<blockhash>) for Chain.block_height (i.e. current generation) previously it returned None. With Bitcoin-NG we do have the block hash of the current generation, so no reason not to allow this
• 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 Auth.tx
• Adds native BLS12-381 crypto pairing operations for zero knowledge proofs
and advanced multi-signature schemes
• New string operations in FATE2 - Adds String.to/from_list Char.to/from_int and Char.to_lower/upper
• String.length from FATE2 returns the length of to_list on the string instead of its byte_size
• Onchain bytecode of new contracts contains the compiler version from FATE2 onwards - previously it was set to “unknown” in FATE1
• Improve the FATE garbage collector - nested maps are now much, much cheaper
• Adds a new named argument “protected : bool” to remote contract calls. A remote call with protected = true gets its result wrapped in an option type, with failing calls returning None. When the protected call fails then any side efects from executing the protected call are rolled back

Done - unmerged:
• Restrict AENS name pointers:
GH-3282 AENS pointers cleanup by hanssv · Pull Request #3447 · aeternity/aeternity · GitHub (scheduled for IRIS-rc1/IRISrc2)
• Deprecate AEVM - GH 3151 AEVM deprecation and cleanup by hanssv · Pull Request #3519 · aeternity/aeternity · GitHub
(scheduled for IRIS-rc1/IRIS-rc2)

Done:
• New transaction - PayingForTx - Allows an account to pay for a transaction on behalf of someone else. Paying for fees and gas cost, will not cover the amount spent by the transaction, just “the cost of the transaction” (and the extra size added by wrapping the original transaction)
• Improves the pricing model of Generalized Accounts
• Changes how a meta transaction TTL’s is being validated: so far it used to be the outermost transaction’s ttl that was taken into account, now it is the innermost one instead. Meta transactions no longer have TTL
• Fixes a protocol issue: a valid force progress call with invalid CallData or failing call will result in on-chain transaction but tokens from the caller would still be moved to the forced contract. This is fixed and failed calls in successful force progress transactions result in rollback of the of-chain balances
• Extend AENS name max expiration time from 50000 generations (~100 days) to 180000 generations (~375 days)
• Improves the functionality of State Channel delegates: now they can provide
channel_solo_snapshot_tx as well. This is really handy in cases one party is missing and the other is doing malicious force progress on-chain while the channel is still open
• Query oracles using AENS names - if an AENS name contains an oracle_pubkey pointer pointing to an onchain Oracle then you can optionally
query that oracle using the name hash instead of the oracle pubkey
• Revisits the State Channel delegates: so far they were a shared list for both participants. From Iris on, delegates are per peer: there is a list of delegates for the initiator and another one for the responder. Old channel objects can still be used but users are strongly recommended to reset their delegates list if they have any. Note that the HTTP representations are changed accordingly.
• Allows delegates to force progress on behalf of the user that authorized them to do so.

These are the changes that we propose the community to vote on to continue strengthtening together the æ technology and æcosystem.

9 Likes
2

I have two questions:

  • will it be possible to verify contract bytecode after the hardfork? (or is that already possible now?)
  • is it possible to set arbitrary pointers (keys and values) or is it foreseen to only set “default pointers” (accounts, channels, oracles, contracts) ?
2 Likes
3

Why is it delayed every time? The dealer also makes you lose confidence.

1 Like
4

whats the definition of a positive outcome?

2 Likes
5

Yes, the design we settled on is:

  • Onchain contracts can query the bytecode_hash of the contract
  • The init function is not stripped(to enable cloning and to ensure that the bytecode_hash verifies everything - you don’t need the original create_tx to verify the bytecode)
4 Likes
6

Take a look at:

3 Likes
7

thanks for the quick response. not sure whether I understand correctly, so basically we only allow the 4 different pointers for accounts, channels, contracts & oracles?

3 Likes
8

when we had the governance episode on the SHL a vote was made on this , and these are the results (the amount of votes is still very low)

3 Likes
9

so what I see there is that:

  • users want to to use separate (claimable) voting tokens for voting
  • don’t want exchange addresses to be included in the voting result

I guess the current implementation of the governance app doesn’t provide this.

so generally speaking I think the question of @philipp.chain remains open. I mean, how do we define that the vote has a positive outcome? (at least we had the majority saying 51% are enough)

so do we say we use the current implementation of the governance app (which probably includes exchange balances) and we vote with AE like we did before and when 51% say yes we have a positive outcome?

6 Likes
10

Hi Marco!! regarding the current implementation and the poll made, for this vote there is a requirement of having 51% support with no minimum amount of stake to vote or number of voters, and we will be heavily communicating about the vote to get as much participation as possible. Cant wait to cast my vote on Monday :)) !!! Have a great weekend !!!

4 Likes
11

More details: Iris Hard fork is here! Prepare to vote! | by æternity blockchain | æternity blog

3 Likes
12

The same! Monday it is <3 :slight_smile:

3 Likes
13

Can’t vote for your wallet in Chinese?Chinese people are not easy to invest

1 Like
14

When will hyperlink go online? Will it be on the meeting?

1 Like
15

Please review this Public AMA Call with our core developers to make up your mind about the Iris Hard Fork Vote:

Don’t forget to vote Poll #45 on https://superhero.com/voting until Tuesday before the community vote ends! :ballot_box:

3 Likes