The proposed changes in Ceres protocol

News and Announcements Core Dev Updates
1

Hi All,

We­’re eager to introduce­ and discuss some proposed changes to the Ceres protocol. Your valuable feedback plays a key role in shaping Ceres’ future. Please, take some time to review and share your thoughts. Let’s talk about this!

Ceres is the 5th protocol upgrade for aeternity; following the initial protocol Roma, we have then seen Minerva, Fortuna, Lima, and Iris. Ceres is the first protocol upgrade not part of the initial update schedule and it contains mainly smaller improvements and enhancements. The protocol documentation can be found at æternity Protocol

Changes summarized

Micro-block gas limit calculation changed: Gas limit was computed from a transaction’s max gas value, now it is computed from the actually used gas.

  • Contracts can be called by name: Just like it is possible to spend to an AENS name, it is now possible to call a function for a name that points to a contract.

  • Generalized Accounts:

    • GAMetaTx parameters (fee and gas_price) are now part of the transaction hash and thus not changeable by a rouge miner.
    • GAAttachTx can only be used by a fresh account.

  • AENS:

    • Adjusted auction parameters - auctions are generally made shorter.
    • Adding raw data pointers.
    • Adding wildcard delegation signature, delegating control for all current, and future, names for an account to a particular contract.
    • PreClaimTx is made optional.

  • FATE:

    • Delegation signatures have been made more structured.
    • Support for dynamic-sized binary arrays (type bytes()) is added.
    • Built-in bitwise operations have been added.
    • Crypto.poseidon - a SNARK-friendly hash function is added.

  • Utility functions Chain.network_id, Address.to_bytes, and Int.mulmod are added.

  • AENSv2 is introduced to support the raw data pointers.

  • BRI - the Block Reward Initiative has been made configurable. The BRI was introduced in Fortuna and hasn’t changed since. In Ceres it has been made a proper part of the configuration, and the mechanism has been updated to allow changing it as part of a protocol upgrade. Values for mainnet and testnet remain hardcoded.

Changes detailed

These changes are provided by the PR’s:
https://github.com/aeternity/aeternity/pulls?q=is%3Apr+label%3Abreaking%2Fconsensus+

Micro-block gas limit

Instead of using max allowed gas when packing micro-blocks we use actual used gas. This allows for more transactions to be packed into a block, increasing throughput and also stopping (accidental) denial of resources when overestimating contract calls, etc. The downside of this is that the transaction has to be applied before its gas usage is used. This puts a little bit of extra burden on the block producer, but, thankfully, block verification is not computationally more expensive.

Contracts called by name

Contracts can be called by name. Just like it is possible to spend to an AENS name, it is now possible to call a function for a name that points to a contract. The key contract_pubkey of the name is resolved while running the transaction. Technically, this has consequences for the contract call structure
(aect_call) that gets a new field with the contract call identifier. To be able to find the call result without doing name resolution calls are stored relative to the id rather than the contract pubkey.
NOTE: Names can change at any time (frontrunning is possible!) so only call contracts by name when you trust the owner of the name!

Generalized Accounts - hardening GAMetaTx

Include fields fee and gas_price in GAMetaTx when computing the TX-hash of the inner transaction. This way a malicious miner can’t change them before inserting the transaction in a macroblock.

Generalized Accounts - limit GAAttachTx

The transaction logic for GAAttachTx is changed, such that, it is only possible to attach authorization code to a fresh account. An account is fresh as long as it hasn’t signed any transactions - effectively, this means that GAAttachTx is only allowed with nonce = 1.
The rationale behind this is to avoid the case where an active account is lured into signing a GAAttachTx, and in practice giving the account keys away.

AENS - Adjusted auction parameters

The AENS auction mechanism is adjusted. Firstly, we make auctions initially shorter, and, secondly, new bids only extend auctions with a short period (and it is only extended if the new bid comes near the end of the auction, i.e. within the extension period).
Names longer than 12 characters, like before, have no auction. Names between 9 and 12 characters have an auction length of 480 generations, approximately 24 hours. Names between 5 and 8 characters have an auction length of 960 generations, approximately 48 hours. Names shorter than 5 characters have an auction length of 2400 generations, approximately 5 days. The extension period is 240 generations, approximately 12 hours.

AENS - Raw data pointers

We introduce a new type of pointer for AENS names. The raw data pointer/value is an arbitrary-sized byte array (max 1024 bytes). And, unchanged, a name can have a maximum of 32 key-pointer pairs. FATE VM and Sophia are updated to allow full access to the new pointer type (See
aesophia/docs/sophia_stdlib.md at master · aeternity/aesophia · GitHub).

AENS - Wildcard delegation signatures

Add generic/wildcard AENS delegation signatures. I.e. instead of delegating authority for a contract to operate with a specific name (name hash), by signing just the network id, public key, and contract address, you can delegate the authority for a contract to handle all your names with one signature. See Issue #4080 for details.
BEWARE: This gives the contract authority to handle all current and future names on your behalf, so it should be used with extreme care and only for well-known (and well-understood!!) contracts.

AENS - Preclaim is optional

Since the introduction of auctions, the front-running protection offered by the
‘PreClaim → Claim’ flow is no longer as important. To simplify name
registrations (or the start of a name auction) we now allow NameClaimTx without
a preceeding NamePreclaimTx. In this case, we set the NameSalt to 0.

FATE - New operations

  • bitwise operations on integers (band, bor, bxor, bnot, << and >>)
  • Address.to_bytes - converting an address to its binary representation
  • Int.mulmod - a combined multiplication and modulus operation for efficiency
  • Crypto.poseidon - a ZK/SNARK friendly hash function
  • Introduce arbitrary sized binary arrays (type bytes()); adding Bytes.split_any,
    Bytes.to_fixed_size, Bytes.to_any_size, Bytes.size, String.to_bytes,
    and Int.to_bytes; and adjust Bytes.concat, and Crypto.verify_sig to allow both
    fixed and arbitrary sized byte arrays.
  • Chain.network_id - the network id of the chain

FATE - Structured delegation signatures

Delegation signatures have been made more structured, and their serialization is part of the protocol description (and their implementation is part of aeserialization). This means that the data for delegation signatures no longer risks overlapping with transactions, and it should be clear what is
signed. This is discussed in #4177 and #4178.

12 Likes
2

I haven’t seen any content about NFT and HC. May I ask if these two sections are involved in this hard fork?

3

What is described here are the (proposed) changes to the Aeternity consensus protocol.

Of course that is not completely unrelated to NFTs and Hyperchains - both NFT contracts and Hyperchains will use the new features and functionality - but they are not a technical part of the Ceres protocol upgrade as presented here.

2 Likes
4

the changes in regards to delegation signatures will allow to simplify the Wrapped AENS application. you can read more about that here:

I already prepared the migration to Ceres back then. but delegation signatures need to be supported by Superhero Wallet. I think I saw some activity on that area recently.

5 Likes
5

Thx for reply :slight_smile:

6

This is an exciting and highly anticipated development, highlighting the efficiency, innovation, and pragmatism of the AE team. I believe Ceres is another important milestone for aeternity, laying a solid foundation for the prosperity of its ecosystem. In particular, the improvements in AENS are expected to generate a strong community response. Shortening the AENS auction time will make the bidding process more challenging and engaging. I am eagerly looking forward to the launch of Ceres.

1 Like
7

I advise very very strongly NOT to change anything about the auction parameters and NOT to allow to NOT do the preclaim transaction for registering a name. Preclaim transaction has to be mandatory to avoid that others (like miners) snap your name before you get it. Avoiding the preclaim transaction will lead to very bad user experience, guaranteed! Also changing the auction parameter is absolutely NOT FAIR for anyone who already bought his name. The value of the dot chain names is getting inflated .
I have no opinion on the raw data pointers or the wildcard delegation.

1 Like
8

I propose additional new changes, which have not been mentioned above:

  1. Optional support of signing transactions with elliptic curve Secp256k1 (same as Bitcoin and Ethereum). Reason: much bigger support for software and hardware (like hardware wallets). Also: deterministic bidirectional derivation of keys (in case not hardened).

  2. Reducing the rolling checkpoint time to 30 minutes. Current the rolling checkpoint time is configurable by the mining pools and set to 180 blocks (approx. 10 hours). (Source: Blocks - Best Aeternity AE Mining Pool - 2Miners ). This means that aeternity users have to wait at least 10 hours for accepting larger amounts of AE which makes æternity blockchain extremely unattractive.

IMO it would be a good decision by the core developers to reduce it to minutes and not to have it configurable.

  1. Resonable transaction fees: IMO the transaction fee are way too low and let users spam the blockchain with unnecessary data. Remember that every full node needs to have a copy of every transaction forever. The current tx fee seems to be 0.00001932 AE which equals to 1 million transactions per USD, if I did the math right. Seems way to cheap for the effort it creates for the network.
9

I suggest to fully REMOVE the BRI. The original goal was to have an income for the foundation to sustain, but with the current prices it is hardly worth a coffee. Better to support the miners with this amount.

2 Likes
10

IMO the consensus protocol needs a big upgrade and the proposed above changes by @Marcin do not bring much value to the chain! The current PoW consensus with the current rolling checkpoint implementation is no good for DEFI as MEV-type attacks are way too easy. And DEFI seems to be the by far the largest use case for decentralised blockchain technology. So until the current consensus mechanism has not been improved to be at least better than Ethereum’s I don’t see a big future for æternity blockchain. Hyperchains was envisioned as a consensus upgrade from my perspective.

Disclaimer: I have no opinion on the changes touching FATE or Generalised Accounts.

11

You haven’t noticed that the AENS names are the original NFTs, or?

12

Yes. For the sake of miners and the network, this tx price is dynamic and should be rising more steeply during the implementation of better tx price adjusting logic in the nodes. this means: empty blocks = cheap couple tx, good for the users, nobody is hurt. Full blocks = pay more to be squeezed in.

Yes, the final checkpoint should give enough room for naturally needed chain reorgs when necessary, but not more than that. @uwiger do you remember what was the original reasoning behind the current configuration?

13

A general note - except for the auction parameters - the rest of the proposed changes are all optional; as a user you don’t need to skip PreClaim, you don’t have to use raw data pointers, and you don’t have to use the new delegation signatures. So in that sense they shouldn’t be too controversial. All changes are the result of users trying to solve a particular problem and most of them have been discussed in the forum and/or Github issues. Notably the delegations signatures and raw data pointers have been advocated for by among others @marco.chain - and the optional PreClaim was a suggestion from the SuperHero team (since they apparently had some technical issues with the current process).

Optional Pre-claim

Regarding making the pre-claim optional - and, again, this is only adding a work-flow - the idea is that with the introduction of auctions (in an earlier protocol upgrade) the frontrunning problem is much less of an issue. The best thing someone on the outside (be it a miner or some other user) can achieve is to make the initial bid on a name - they will not snipe the name. However, for longer names (13+ characters) where there is no auction, or if you are very, very eager to make the first bid on a name, nothing stops you from using the PreClaim! (Perhaps the Superhero team can chime in since they were one of the strong advocates of this, claiming it would lead to a better user experience)

Adjusted auction parameters

There was long discussion regarding this on the forum - where there were basically three camps:

  • Group 1 - wanted short auctions (hours) and really short extensions (minutes)
  • Group 2 - wanted shorter auctions (days) and shorter extensions (hours/days).
  • Group 3 - wanted status quo, i.e. auctions in (days/months) and extensions in (days/months)

None of the groups were in a huge majority, though group 1 and 3 were most vocal, but in the end the result was a proposal landing in the middle in true democratic style.

Lastly, I have to admit that I don’t see why the change in auction length is unfair to those who have bought names in the past?

1 Like
14

I don’t see how you can claim that his has been democratic when there was no voting on it at any level. From my perspective it was the initiative of ONE guy (@marco.chain ) to change this.

I suggest to everyone here to vote AGAINST ceres upgrade with it’s above described scope. :-1: :-1: :-1:

Many more people seem to be against changing anything about the auction parameters. 缩短AENS拍卖时间的建议非常糟糕 The proposal to shorten the auction time of AENS is very bad - #7 by YaniUnchained

15

You want to say democracy, did you pass the vote when BRI, you are the biggest undemocracy. :-1: :-1: :-1: :-1: :-1:

I would say that more people support such a change, 90% of the people who own AE near me support shortening the auction of domain names. Of course, I also support the voting process.

16

Most people are support it, because the proposal already includes a reduction in time, so they don’t come out and speak out. And it is often the naysayers who speak out.

17

Hi, Hans. There is only one issue regarding the PreClaim transaction on Superhero Wallet side. And there is no suggestion to delete it.

Earlier in our face-to-face Superhero Wallet team meeting, we were brainstorming on the name functionality. And one of the frustrating parts of that functionality, from a user experience perspective, was that we were showing two modals for confirming name registration. Preclaim and Claim. And it was suggested that we make one modal with current registrations process status.

...PreClaiming
....done V
....claiming 
.... done V

We can also offer the user to decide how they want to register their name. Of course with a detailed explanation of possible problems.

Current rare issues that user may encounter when using PreClaim and Claim transactions in wallet. Will be fixed with the introduction of nonce management on the wallet or sdk side.

18

I have to admit I didn’t understand the post about how it is unfair that we auction out the names now and don’t wait for the millions of people (on X?) that has yet to discover Aeternity :thinking:

This discussion had at quite a few different people discussing the auctions, including four different polls - so at least there was some effort to gather different opinions.

And remember this is just at proposal, the plan is, I guess, to have vote on it, just like we have done in the past!?

19

I’m glad to hear there are finally plans to do proper nonce-handling :tada:

Sounds like making the PreClaim optional wasn’t much needed then - but it wasn’t a very big feature either. At the end of the day it might simplify some use-case somewhere - and if you don’t like it, then just pretend it isn’t there :sweat_smile:

2 Likes
20

We also duscussed AENS claim/preclaim in this issue

I still think it is useful to have preclaim optional.

1 Like