Split NEP-141 logic outside of Engine

AIPs (Aurora Improvement Proposals)
1

From: Evgeny Ukhanov

Motivation

The logic of separation proposal is related to several aspects:

  • improved security (due to a number of vulnerabilities found recently)
  • more flexible changes (this will not require updating the entire aurora contract)

Technically, this involves moving the logic of Fungible Tokens (NEP-141) and related data into a
separate NEAR contract.

Interactions with the contract will be carried out through cross-contact calls (AIP-2).

Risks

The logic of interaction with Funginle Token, which implements the NEP-141 standard, is not trivial
and is one of the key aspects of the Aurora contract, and requires a design review and careful
implementation. This can complicate the logic of interaction with Fungible Tokens.

The risks also include the transfer of data to another contract. These data are extremely sensitive and embody the economic component of the contract - tokens. Which imposes special requirements and
accuracy when migrating data to a new contract.

Discussion

Considering the benefits and risks, an important aspect is a discussion by the community and
developers and the adoption of the optimal decision and design.

3 Likes
2

From: Michael Birch

A few quick points from me:

  • I think having a separate nep-141 contract will be lower risk than having it in the engine when it comes to correctly implementing the standard and interacting with other fungible tokens. This is because we can start with Near’s standard implementation or the implementation used for other bridged tokens, both of which are known to work properly. The engine’s code was written from scratch due to it needing to be no-std and this introduced many problems at the beginning; problems that will be avoided by starting with known template.
  • l agree the data migration must be done with extreme care and this represents the greatest risk of going the separate contract route. An alternative proposal (the preferred option by @marcelo.near | think) which avoids this risk is to only separate the nep-141 logic on a software level to avoid the direct engine interaction that caused the previous security vulnerabilities. However, I am skeptical this approach has enough of the benefits that the complete separation offers. I would be interested in hearing arguments from others in either direction.
3

From: Joshua J. Bouw

do agree it’ll reduce our risks on the engine itself, therefore it is a worthy time investment to
implement this change.

4

From: marcelo.near

One of the main drawbacks I see of moving ETH outside of Aurora contract (apart from technical
challenges), is the noise it creates in the ecosystem, by forcing everyone to switch the token
address from one account to a different account.
Doing a logical separation (inside ‘aurora’ contract), as mentioned by @birchmd, seems to me a
better path, given the main goal of the separation is security wise. As part of this logical separation,
we must stop depending on receipts proofs to bridge assets, and instead depend on state proofs.

5

From: Evgeny Ukhanov

It’s not obvious to me what you mean by logical separation in terms of interacting with storage.
Also unclear why:

by forcing everyone to switch the token address from one account to a different account

I can’t see cases when token addresses should be switched.
Also, what do you mean “state proofs”?

6

From: marcelo.near

logical separation

NEP-141 ETH logic is kept inside ‘aurora’ contract, but the code is reworked in such a way that engine and connector are completely separate entities, with different entry points and close to zero overlap.

by forcing everyone to switch the token address from one account to a different
account

Every contract out there that manages ETH automatically will have ‘aurora’ contract hardcoded as the home contract for ETH implementation. If you move it to eth.near later, the contract they are pointing to for dealing with balances, give rewards, credits and debits must be changed. Think of ref.finance giving some rewards in ETH, they have hardcoded ‘aurora’

what do you mean “state proofs”?

Bridge uses today proofs of receipts to highlight events that took place in some chain. It is possible that some overlap of receipts could exist by calling different methods. If events are stored in the state, proofs could be built against such events, without conflicts between different methods generating similar receipts.

7

From: Joshua J. Bouw

I don’t think that the word is noise, but the fact that it would break processes of others, forcing
them to spend money to also upgrade their systems in time for when we launch the change.

This is an issue because there are three ways we can handle this:
a) Everyone pauses UNTIL new engine is released with the changes
b) We choose a future block date for the changes to start
c) For a time we allow people to continue using the Engine’s contract but they need to expect
by a certain point, they need to be migrated to the new contract

C obviously is more preferred in this case.

8

From: Joshua J. Bouw

Do note that we do require discussion and commentary before we put an AIP together which will
allow us to commit to this change and begin work.

Public discussion is necessary as this affects beyond our own systems and introduces large
breaking changes to the Engine.

9

From: Hyungsuk Kang

Separation is necessary for better code management, but I think we have to consider reentrancy
attacks on conversion between NEP-141.

10

From: Joshua J. Bouw

Of course, we need to include all necessary potential attack vectors in the AlP, including
potential reentrancy attacks.

12

Below are a few questions relating to the reasons driving the proposal:

1. Security

  • Does the separation reduce the number of existing risks AND/OR their impact?
  • If yes, what would be the Old vs. New (with the separation implementation) Risk Matrix?
  • Does the separation involve new risk items (non-existent today) to handle / manage in the future?

2. Scalability

  • To what extent the separation will facilitate the deployment of new contracts on the Aurora contract?
  • Does the new design allow new development functionalities/capabilities?
  • Does the AS IS logic slow down / restrain the deployment of more FT Contracts AND their interactions with addresses (incl. contracts)?

Because the new logic, along with its potential implementation, has a significant impact on the inner working of existing projects, I think the narrative of ‘why the change’ should be extremely solid and documented.

Let’s assume the change must occur. The scope of impacted stakeholders would be:

  • Plain addresses holding the FT (balance != 0)
  • Contracts holding the FT (balance != 0)
  • Contracts managing FT contract calls (ie Ref Finance)

Plus, is there not another element to take into account for tokens with multi-environment presence (NEAR-native, Aurora contract, Ethereum)?

Regarding a potential migration, I think we would need a Master Plan with a clear owner to handle the coherence and synchronisation of such a change across all impacted market participants.

Am I correct to assume that such a migration involves a transfer of risks from the current contracts to the ‘body’ (tech and team) responsible of the migration?

To avoid such a risk, would it be an alternative to have a new version of the FT contract for every concerned contract? Reducing the utility of the old version and their presence at the frontend level while transferring the utility to the new contracts, as we successfully did in the past for the migration from WETH to ETH (details).

13

@birchmd The current implementation with improvements has been around for almost 1.5 years. In fact, you propose to rewrite based on the template, but not on the existing code base, taking into account the specifics of the Aurora contract.

For example, the biggest bug, in fact, indirectly related directly to the NEP-141 logic, and when transferred, it will still remain part of the Aurora contract.

Rewriting a codebase from scratch that is tested and currently stable looks like a venture/gamble to me.

Also an open question is what exactly to transfer to a separate contract. What Marcelo is talking about is reasonable, but it is not at all obvious at first glance what exactly should be transferred in the context NEP-141. The main reason is that by design the FY data is stored in the contract itself.

And this, by definition, excludes the use of ready-made solutions.

The main reason for using non-std was gas consumption. I can assume that the use of template solutions may entail an increase in the gas used. This is despite the fact that calling an external contract also consumes gas. It is for this reason that I consider it very important not only the business part, but also the specific design of the implementation.

14

@Didier Thanks for the questions!
Now point by point

Does the separation reduce the number of existing risks AND/OR their impact?

I believe that yes, this is one of the motivational aspects

If yes, what would be the Old vs. New (with the separation implementation) Risk Matrix?

We reduce the code base and business logic of the main contract, which is error prone.

To new risks, I would include the obvious fact that the existing functionality and code base - after a number of edits in the history of its existence - is stable. Whereas the new implementation may contain errors and vulnerabilities, despite all the thoroughness of test coverage and code reviews.

Does the separation involve new risk items (non-existent today) to handle / manage in the future?

It is possible. See above.

To what extent the separation will facilitate the deployment of new contracts on the Aurora contract?

In my understanding, this is about flexibility and simplification of the process. And most importantly, this is an isolated functionality, and not the entire contract.

Does the new design allow new development functionalities/capabilities?

There is no new design. That’s what the current discussion is for. However, this is clearly the focus.

Does the AS IS logic slow down / restrain the deployment of more FT Contracts AND their interactions with addresses (incl. contracts)?

I don’t think so.

Because the new logic, along with its potential implementation, has a significant impact on the inner working of existing projects, I think the narrative of ‘why the change’ should be extremely solid and documented.

Absolutely reasonable remark. And in this aspect, I really hope for the help of all those interested in this, in preparing draft AIP.