The ERC-721 standard has become very popular these days. In NFTStudio we have thought about how to make the NFT standard a little more interesting by attaching additional information to the OpenZeppelin proposed HERE.
We hope that our proposals are interesting.
If you would like to propose changes or add comments, please feel free to open an issue.
Licenses
First of all, given the application of NFTs in the fields of art or music, we thought about licenses. We believe there are at least two issues to address when pushing something digital on the internet and the blockchain:
- a public license issue, originating from uploading the file to the archive or because it is visible on servers and websites;
- an owner / creator licensing issue as the file, coined as NFT, was created by a party who owns it;
To solve the licensing issue we have decided to use the Creative Commons licenses, as they are already accepted by the artists and because they specify the permitted use of a file distributed on the Internet.
For the owner license we use the Nifty license, already widely adopted in the blockchain space.
Of course it is possible to add other licenses: our contribution lies in having identified the need, in our opinion, to add them directly in the metadata.
Certificate of Authenticity
A work of art cannot be considered original without its certificate of authenticity. Consequently, the CA will also have to be added in the metadata, so that every buyer can be 100% sure that the file is original and issued directly by the author. You can find our CA elaboration HERE.
As you can see, we have attached all important information regarding the artist and / or author and the file.
An additional important information is represented by the digital identity of the artist, which is typically represented by the public address of his wallet.
As Tim Daubenschütz has exposed HERE, we cannot rely only on a token issued by someone as anyone can mint a token directly on another’s account.
We will explain our improvement in the next paragraph.
Cryptographical proof
As is widely known, a digital identity is made up of a pair of keys, one public and one private. When we have to expose our key we use the public key, as we do to indicate the artist’s identity.
On the other hand, when it is necessary to identify yourself (sign) to carry out transactions or otherwise, we use the private key. By signing the data, a cryptographic proof is generated which can be used to verify if an address has actually signed the data.
Adding this proof to our NFT implies that even if someone coined the NFT on behalf of an author / artist (eg a platform that carries out the minting by taking on the fees) it is always possible to verify that the author has given the consent creation of the NFT.
We have created two simple tools for signing and verifying proofs: you can use them to create the proof and use this template to paste the proof.
The object of the test must be the CA, which possess all the fundamental information of the NFT itself.
We can therefore argue that the NFT is the CA and not the media file itself.
If you want to test and use our tools, you can install node dependencies:
cd signing-tools
npm install
To sign a message, provide a private key in the parameter p and a message in the parameter m:
node sign -p=4af1bceebf7f3634ec3cff8a2c38e51178d5d4ce585c52d6043e5e2cc3418bb0 -m=’Hello World’
The result will be:
SIGNATURE: 0xbe7c7df2ba38d81a197329247bfdb9ab16a771e3fc80843249d6290898ef83d0025893a360ea234265f9ea92c197bf034b7a6a4c8e303042cf440a33bbbb92861c
SIGNED BY ADDRESS: 0x29c76e6ad8f28bb1004902578fb108c507be341b
To verify a message provide the signature in the parameter s and the message in the parameter m:
node verify -s=0xbe7c7df2ba38d81a197329247bfdb9ab16a771e3fc80843249d6290898ef83d0025893a360ea234265f9ea92c197bf034b7a6a4c8e303042cf440a33bbbb92861c -m=’Hello World’
The result will be:
THIS MESSAGE WAS SIGNED BY ADDRESS: 0x29c76e6ad8f28bb1004902578fb108c507be341b
As you can see we have cryptographically proved that 0x29c76e6ad8f28bb1004902578fb108c507be341b signed the message Hello World.
Storage
Another important issue regarding NFTs, if we assume that this NFT should be easily reproduced, is the storage of the files themselves.
All the information present in the metadata are links, which means that the files they refer to must be hosted somewhere on the Internet, inside servers that are constantly (and theoretically forever) ready to provide what is requested.
One of the simplest solutions to make sure a file exists forever is, as always, to use a standard created for it. Fortunately, this standard exists and is called IPFS.
If you’re new to IPFS, don’t worry: there are plenty of easy services (like Textile or Pinata) that make the upload and pinning process easier.
As mentioned above, there are two things we can do to make sure our files are always available. The first is to use a standard and upload the file to any IPFS node. The second is pinning, which is the operation of making a file persistent over IPFS.
Using one of the services mentioned above, pinning will be done on its own. If you prefer to do it independently or using your IPFS node you have to start from HERE.
Anatomy of an NFT
The proposed improvements can be easily understood by analyzing the json, of which you can find a copy HERE:
{
“name”: “<TITLE>”,
“description”: “<DESCRIPTION>\n\n\n — \n\n\nPublic License:\n<PUBLIC_LICENSE>\n\nOwner License:\n<OWNER_LICENSE>\n\nCertificate of Authenticity:\n<CA_IPFS_HASH>”,
“image”: “<IMAGE_IPFS_HASH>”,
“external_url”: “<EXTERNAL_URL>”,
“certificate_of_authenticity”: “<CA_IPFS_HASH>”,
“owner_license”: “<OWNER_LICENSE_IPFS_HASH>”,
“public_license”: “<PUBLIC_LICENSE_IPFS_HASH>”,
“proof”: “<PROOF_IPFS_HASH>”
}
ITA
Lo standard ERC-721 è sempre più popolare in questo periodo. In NFTStudio abbiamo ragionato a come rendere lo standard NFT più interessante e completo, allegando alcune informazioni aggiuntive all’OpenZeppelin (QUI).
Ci auguriamo che le nostre proposte siano considerate interessanti. È possibile proporre modifiche o aggiungere commenti, non esitate ad aprire un issue sul nostro GitHub.
Licenze e certificazioni
Innanzitutto, vista le numerose applicazioni degli NFT nel campo dell’arte o della musica, abbiamo pensato alle licenze.
Crediamo che ci siano almeno due problemi da affrontare quando si carichi un file su Internet e sulla blockchain:
i. un problema di public license, originato dal caricamento del file in uno storage, o perché è visibile su server e siti web;
ii. un problema di certificazione di proprietà o di creazione poiché il file, coniato come NFT, è stato creato da un soggetto che lo possiede o meno.
Per risolvere il problema delle licenze abbiamo deciso di utilizzare le licenze Creative Commons, in quanto sono già accettate dagli artisti e perché specificano l’uso consentito di un file distribuito su Internet. Per il certificato di proprietà utilizziamo la licenza Nifty, già ampiamente adottata nello mondo blockchain.
Ovviamente è possibile aggiungere altre licenze: il nostro contributo sta nell’aver individuato la necessità, a nostro avviso, e di averle aggiunte direttamente nei metadati dello smart-contract.
Certificazione di autenticità
Un’opera d’arte non può essere considerata originale senza il suo certificato di autenticità. Di conseguenza, nei metadati dovrà essere aggiunta anche la CA in modo che ogni acquirente possa essere sicuro al 100% che il file sia originale ed emesso direttamente dall’autore.
Puoi trovare la nostra elaborazione CA QUI.
Come puoi vedere, abbiamo allegato tutte le informazioni importanti riguardanti l’artista e / o l’autore ed il file. Un’ulteriore importante informazione è rappresentata dall’identità digitale dell’artista, che tipicamente è rappresentata dall’indirizzo pubblico del suo portafoglio.
Come ha esposto Tim Daubenschütz QUI, non possiamo fare affidamento solo su un token emesso da qualcuno poiché chiunque può coniare un token direttamente sull’account di un altro. Spiegheremo il nostro miglioramento nel prossimo paragrafo.
La prova crittografica
Come è noto, un’identità digitale è composta da una coppia di chiavi, una pubblica e una privata. Quando dobbiamo esporre la nostra chiave usiamo la chiave pubblica, come facciamo per indicare l’identità dell’artista.
Quando invece è necessario identificarsi (firmare) per effettuare transazioni o altro, utilizziamo la chiave privata. Firmando i dati, viene generata una prova crittografica che può essere utilizzata per verificare se un indirizzo ha effettivamente firmato i dati. Aggiungere questa prova al nostro NFT implica che anche se qualcuno avesse coniato l’NFT per conto di un autore / artista (es. Una piattaforma che effettua il conio assumendosi i corrispettivi) è sempre possibile verificare che l’autore abbia dato il consenso alla creazione del suddetto NFT.
Abbiamo creato due semplici strumenti per firmare e verificare le prove: puoi usarli per creare la prova e utilizzare questo modello per incollare la prova.
L’oggetto del test deve essere la CA, che possiede tutte le informazioni fondamentali dell’ NFT stesso. Possiamo quindi sostenere che l’NFT è la CA e non il file multimediale stesso.
Se desideri testare e utilizzare i nostri strumenti, puoi installare le node dependencies qui.
Storage
Un altro problema importante per quanto riguarda gli NFT, se assumiamo che questo NFT dovrebbe essere facilmente riprodotto, è l’archiviazione dei file stessi.
Tutte le informazioni presenti nei metadati sono link, il che significa che i file a cui si riferiscono devono essere ospitati da qualche parte su Internet, all’interno di server che sono costantemente (e teoricamente per sempre) pronti a fornire quanto richiesto.
Una delle soluzioni più semplici per assicurarsi che un file esista per sempre è, come sempre, utilizzare uno standard creato per questa ragione. Fortunatamente, questo standard esiste e si chiama IPFS.
Se sei nuovo su IPFS, non preoccuparti: ci sono molti servizi facili (come Textile o Pinata) che semplificano il processo di caricamento e blocco.
Come accennato in precedenza, ci sono due cose che possiamo fare per assicurarci che i nostri file siano sempre disponibili.
La prima è utilizzare uno standard e caricare il file su qualsiasi nodo IPFS. Mentre la secondo è il pinning, che è l’operazione di rendere un file persistente su IPFS.
Utilizzando uno dei servizi sopra menzionati, il blocco verrà eseguito da solo. Se preferisci farlo in autonomia o utilizzando il tuo nodo IPFS devi iniziare da QUI.
Anatomia di un NFT
I miglioramenti proposti possono essere facilmente compresi analizzando il json, di cui puoi trovare una copia QUI:
{
“name”: “<TITLE>”,
“description”: “<DESCRIPTION>\n\n\n — \n\n\nPublic License:\n<PUBLIC_LICENSE>\n\nOwner License:\n<OWNER_LICENSE>\n\nCertificate of Authenticity:\n<CA_IPFS_HASH>”,
“image”: “<IMAGE_IPFS_HASH>”,
“external_url”: “<EXTERNAL_URL>”,
“certificate_of_authenticity”: “<CA_IPFS_HASH>”,
“owner_license”: “<OWNER_LICENSE_IPFS_HASH>”,
“public_license”: “<PUBLIC_LICENSE_IPFS_HASH>”,
“proof”: “<PROOF_IPFS_HASH>”
}
Per saperne di più accedi al github dedicato: erc721-improved-standard
