Refactor with NEAR standard NEP141 #2
Conversation
….com:aurora-is-near/aurora-eth-connector into feat/use-near-standard-nep141-implementation
|
@birchmd unfortunately, gas costs for migration increased twice (!). AFAIK it depends on how currently storage key is organized. Specifically |
|
A factor of 2 is a large increase. It's not clear to me why this increase happens. You say it's because of the proof keys, but it looks like both before and after this change they were contained in a Also, is this factor of 2 increase a problem for this migration? |
There was a problem hiding this comment.
That was a larger PR than I expected. The tests are still failing, that really needs to get fixed. Large gas costs may have measured higher in workspaces perhaps? Or, NEAR's contract impl have a bit more checks in it. I don't really see what could've caused it but generally, if there are gas cost increases it is quite important to find out why.
It was changed after the proposal in: near/near-workspaces-rs#255 , Opened 2 issues about that. Currently no success. |
|
Whats the status on this? |
…ript chore: remove cache restoring from CI script
Fix pub key for registrar account creation
…ests chore: use four threads for tests and features refactoring
Overview
To significantly simplify the contract, as well as to avoid potential errors and pitfalls associated with the implementation of the NEP-141, the contract is being refactored with a library
near-standarddependency.What is removed
All implementations related to Fungible TOkens. And introduced dependency from
near-standard.Breaking changes
NEP-141 basic (
ft_transfer,ft_transfer_call) methods are now public, without access right control.All related methods were also removed.
All types, that were related to NEP-141 implementation are deleted.
Tests
Tests refactored qith new types dependencies and with keep in mind of new changes
Gas cost
Gas cost increase x2 (twice) for migrations. It relates to a new organization of storage key.