neo-project/non-native-contracts

non-native-contracts's Issues

Better edge cases and exceptions handling for NNS contract

Problem

NNS contract aborts VM execution in case if getAllRecords is requested for unexisting name:
https://github.com/neo-project/non-native-contracts/blob/8d72b92e5e5705d763232bcc24784ced0fb8fc87/src/NameService/NameService.cs#L378C42-L378C60

Tested on test contract invocations. The engine's FAULT exception itself looks like this if C# node handles invokefunction RPC call:

One of the identified items was in an invalid format.

and if Go node handles invokefunstion RPC call, then exception looks like the following:

at instruction 57 (SYSCALL): invalid conversion: Null/ByteString

The reason is in fact that if nameMap[tokenKey] doesn't contain provided tokenKey then Null stackitem will be returned from this call. And then this Null is being passed to (NameState)StdLib.Deserialize which has an offset 57 (according to native StdLib manifest):

               {
                  "offset" : 56,
                  "name" : "deserialize",
                  "returntype" : "Any",
                  "parameters" : [
                     {
                        "type" : "ByteArray",
                        "name" : "data"
                     }
                  ],
                  "safe" : true
               },

As a result, StdLib tries to convert provided Null to ByteString and fails.

Suggestion

The problem itself is in the fact that NNS doesn't properly handle this error and returns it to the user "as is". From this error it's not clear what happens on the contract side and why getAllRecords FAULTs execution. I'd suggest to return some meaningful exceptions from NNS in similar cases.

Also, for this particular case I'd suggest to return empty iterator since there are no suitable records. Not FAULT the execution.

Do you think we should support multiple TXT records for a single name?

@roman-khimov @shargon

process of expired name

So do we remove the deletion logic of the expired date? Is it possible to provide Storage.FindRange method to find items in certain range?

CNAME setting and processing in NNS

I'm not sure NNS supports CNAME properly now, the behavior allows to set CNAME along with other types (like A or AAAA) and at the same time any non-CNAME record overrides CNAME in resolve. I don't think it's expected if we're roughly following DNS logic:
https://datatracker.ietf.org/doc/html/rfc1034#section-3.6.2
https://datatracker.ietf.org/doc/html/rfc2181#section-10.1

clear expired record failed

contract on N3T4: 0x538355b776538a5da0b2a08c139b9900b9c0cbb6

the records are reserved.

NeoNS - improve handling of expired names

Based on the current code, once a domain expired, anyone can register it again, which effectively creates a new NFT.

While this works fine, this means we will end up with 2 (or more) NFT of the same domain, some expired and one not expired, with all the expired one basically useless (can not even be moved).

ENS handles that by burning the old one, during a registration if the old one exists and has expired, is this something we could add? I think this would be cleaner and would avoid ending up with tons of NFT which can not even be moved.

Is this the NNS deployed to MainNet?

Hi,

Is it possible to call this smart contract on main net? Where can we get the hash of it? Also, where are you guys planning to store these non native contracts script hashes?

When buying a domain does not create an NFT

neo.link does not generate NFT when you buy a domain. This problem started three days ago

Renew() miss an event when success

Renew() missed an event when success so that backend tracker can't get notification of details.

Were these contracts deployed on MainNet?

Hi,

Is it possible to call this smart contract on main net? Where can we get the hash of it? Also, where are you guys planning to store these non native contracts script hashes?
What about TestNet? What is the hash? Thanks!

NameService: unexpected IPv6 record constraint

Problem

Unexpected NameService IPv6 record constraint (https://github.com/neo-project/non-native-contracts/blob/master/src/NameService/NameService.cs#L476):

if (fragments[0] != "2001") return false;

Expected behaviour

if (fragments[0] == "2001") return false;

Reverse Lookup

Hey all 👋

It's beyond my understanding why the "reverse lookup" feature was left behind in NNS. Someone pointed me to the (old) PR #15, which was not merged into the NNS initial release.

Basically, right now, no dApp can display blah.neo when pairing its wallet, exactly because we don't have a way to reverse and "find" the name associated with that address.

References:
https://eips.ethereum.org/EIPS/eip-181

NNS Contracts Hashes

I am adding NNS to the neo-cli node. I need to know these contract hashes for

• Network 894710606 (seed1t5.neo.org)
• Network 91414437 (morph1.fs.neo.org)
• Network 91466898 (morph01.testnet.fs.neo.org)

Maybe you guys know or know someone? @shargon @superboyiii

should we add number of years for renew function

since some users will renew for many years, it's inconvenience to call the renew function multiple times. So it's better to add a years parameter to the renew function.

Move CommitteeInfoContract to this repo

current location https://github.com/Ashuaidehao/CommitteeInfoContract