Java chaincode implementation for ERC721 standard token. #670

renjithpta · 2022-03-06T04:53:25Z

Java HLF chaincode implementation of ERC721 is a standard. This standard is used for representing ownership of non-fungible tokens.

...n-erc-721/chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/models/NFT.java

.../chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/ERC721TokenContract.java

...n-erc-721/chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/models/NFT.java

jkneubuh

Hi @renjithpta

Thanks for the Java ERC721 contribution. I have some minor suggestions on code formatting, style, and can not vouch for the accuracy of the routines in the PR. But overall - it looks good.

Some really minor comments, inline below.

jkneubuh · 2022-03-31T19:37:28Z

One final comment on the review of the Java source. If your code introduces the use of final modifiers, please ensure that either ALL of the immutable variables in the scope of the routines are marked as final, or NONE of them are declared as final.

Thanks @renjithpta !

ERC 721 implementation of java chaincode. Signed-off-by: renjithkn@gmail.com <renjithkn@gmail.com> Signed-off-by: renjithpta <renjithkn@gmail.com>

Signed-off-by: FIRST_NAME LAST_NAME <renjithkn@gamil.com> Signed-off-by: renjithpta <renjithkn@gmail.com>

The ERC-721 token smart contract demonstrates how to create and transfer non-fungible tokens. Non-fungible tokens represent ownership over digital or physical assets. Example assets are artworks, houses, tickets, etc. Non-fungible tokens are distinguishable and we can track the ownership of each one separately. In ERC-721, there is an account for each participant that holds a balance of tokens. A mint transaction creates a non-fungible token for an owner and adds one token in the owner's account. A transfer transaction changes the ownership of a token from the current owner to a new owner. The transfer also debits one token from the previous owner's account and credits one token to another account. In this sample it is assumed that only one organization (played by Org1) is in an issuer role and can mint new tokens into their account, while any organization can transfer tokens from their account to a recipient's account. Accounts could be defined at the organization level or client identity level. In this sample accounts are defined at the client identity level, where every authorized client with an enrollment certificate from their organization implicitly has an account ID that matches their client ID. The client ID is simply a base64-encoded concatenation of the issuer and subject from the client identity's enrollment certificate. The client ID can therefore be considered the account ID that is used as the payment address of a recipient. In this tutorial, you will mint and transfer tokens as follows: - A member of Org1 uses the `MintWithTokenURI` function to create a new non-fungible token into their account. The `MintWithTokenURI` smart contract function reads the certificate information of the client identity that submitted the transaction using the `GetClientIdentity.GetID()` API and creates a non-fungible token associated with the client ID with the requested token ID. - The same minter client will then use the `TransferFrom` function to transfer a non-fungible token with a requested token ID to the recipient's account. It is assumed that the recipient has provided their account ID to the transfer caller out of band. The recipient can then transfer tokens to other registered users in the same fashion. ## Bring up the test network You can run the ERC-721 token transfer scenario using the Fabric test network. Open a command terminal and navigate to the test network directory in your local clone of the `fabric-samples`. We will operate from the `test-network` directory for the remainder of the tutorial. ``` cd fabric-samples/test-network ``` Run the following command to start the test network: ``` ./network.sh up createChannel -ca ``` The test network is deployed with two peer organizations. The `createChannel` flag deploys the network with a single channel named `mychannel` with Org1 and Org2 as channel members. The -ca flag is used to deploy the network using certificate authorities. This allows you to use each organization's CA to register and enroll new users for this tutorial. ## Deploy the smart contract to the channel You can use the test network script to deploy the ERC-721 token contract to the channel that was just created. Deploy the smart contract to `mychannel` using the following command: ``` ./network.sh deployCC -ccn token_erc721 -ccp ../token-erc-721/chaincode-javascript/ -ccl javascript ``` The above command deploys the chaincode with short name `token_erc721`. The smart contract will use the default endorsement policy of majority of channel members. Since the channel has two members, this implies that we'll need to get peer endorsements from 2 out of the 2 channel members. Now you are ready to call the deployed smart contract via peer CLI calls. But let's first create the client identities for our scenario. ## Register identities The smart contract supports accounts owned by individual client identities from organizations that are members of the channel. In our scenario, the minter of the tokens will be a member of Org1, while the recipient will belong to Org2. To highlight the connection between the `GetClientIdentity().GetID()` API and the information within a user's certificate, we will register two new identities using the Org1 and Org2 Certificate Authorities (CA's), and then use the CA's to generate each identity's certificate and private key. First, we need to set the following environment variables to use the Fabric CA client (and subsequent commands). ``` export PATH=${PWD}/../bin:${PWD}:$PATH export FABRIC_CFG_PATH=$PWD/../config/ ``` The terminal we have been using will represent Org1. We will use the Org1 CA to create the minter identity. Set the Fabric CA client home to the MSP of the Org1 CA admin (this identity was generated by the test network script): ``` export FABRIC_CA_CLIENT_HOME=${PWD}/organizations/peerOrganizations/org1.example.com/ ``` You can register a new minter client identity using the `fabric-ca-client` tool: ``` fabric-ca-client register --caname ca-org1 --id.name minter --id.secret minterpw --id.type client --tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem ``` You can now generate the identity certificates and MSP folder by providing the minter's enroll name and secret to the enroll command: ``` fabric-ca-client enroll -u https://minter:minterpw@localhost:7054 --caname ca-org1 -M ${PWD}/organizations/peerOrganizations/org1.example.com/users/minter@org1.example.com/msp --tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem ``` Run the command below to copy the Node OU configuration file into the minter identity MSP folder. ``` cp ${PWD}/organizations/peerOrganizations/org1.example.com/msp/config.yaml ${PWD}/organizations/peerOrganizations/org1.example.com/users/minter@org1.example.com/msp/config.yaml ``` Open a new terminal to represent Org2 and navigate to fabric-samples/test-network. We'll use the Org2 CA to create the Org2 recipient identity. Set the Fabric CA client home to the MSP of the Org2 CA admin: ``` cd fabric-samples/test-network export PATH=${PWD}/../bin:${PWD}:$PATH export FABRIC_CA_CLIENT_HOME=${PWD}/organizations/peerOrganizations/org2.example.com/ ``` You can register a recipient client identity using the `fabric-ca-client` tool: ``` fabric-ca-client register --caname ca-org2 --id.name recipient --id.secret recipientpw --id.type client --tls.certfiles ${PWD}/organizations/fabric-ca/org2/tls-cert.pem ``` We can now enroll to generate the recipient's identity certificates and MSP folder: ``` fabric-ca-client enroll -u https://recipient:recipientpw@localhost:8054 --caname ca-org2 -M ${PWD}/organizations/peerOrganizations/org2.example.com/users/recipient@org2.example.com/msp --tls.certfiles ${PWD}/organizations/fabric-ca/org2/tls-cert.pem ``` Run the command below to copy the Node OU configuration file into the recipient identity MSP folder. ``` cp ${PWD}/organizations/peerOrganizations/org2.example.com/msp/config.yaml ${PWD}/organizations/peerOrganizations/org2.example.com/users/recipient@org2.example.com/msp/config.yaml ``` ## Mint a non-fungible token Now that we have created the identity of the minter, we can invoke the smart contract to mint a non-fungible token. Shift back to the Org1 terminal, we'll set the following environment variables to operate the `peer` CLI as the minter identity from Org1. ``` export CORE_PEER_TLS_ENABLED=true export CORE_PEER_LOCALMSPID="Org1MSP" export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/minter@org1.example.com/msp export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt export CORE_PEER_ADDRESS=localhost:7051 export TARGET_TLS_OPTIONS="-o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt" ``` The last environment variable above will be utilized within the CLI invoke commands to set the target peers for endorsement, and the target ordering service endpoint and TLS options. We can then invoke the smart contract to mint a non-fungible token with a unique token ID `101`: ``` peer chaincode invoke $TARGET_TLS_OPTIONS -C mychannel -n token_erc721 -c '{"function":"MintWithTokenURI","Args":["101", "https://example.com/nft101.json"]}' ``` The mint function validated that the client is a member of the minter organization, and then create a new non-fungible token for the minter. We can check the minter client's account balance by calling the `ClientAccountBalance` function. ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"ClientAccountBalance","Args":[]}' ``` The function queries the balance of the account associated with the minter client ID and returns: ``` 1 ``` We can also check the owner of the issued token by calling the `OwnerOf` function. ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"OwnerOf","Args":["101"]}' ``` The function queries the owner of the non-fungible token associated with the token ID and returns: ``` x509::/C=US/ST=North Carolina/O=Hyperledger/OU=client/CN=minter::/C=US/ST=North Carolina/L=Durham/O=org1.example.com/CN=ca.org1.example.com ``` ## Transfer a non-fungible token The minter intends to transfer a non-fungible token to the Org2 recipient, but first the Org2 recipient needs to provide their own account ID as the payment address. A client can derive their account ID from their own public certificate, but to be sure the account ID is accurate, the contract has a `ClientAccountID` utility function that simply looks at the callers certificate and returns the calling client's ID, which will be used as the account ID. Let's prepare the Org2 terminal by setting the environment variables for the Org2 recipient user. ``` export FABRIC_CFG_PATH=$PWD/../config/ export CORE_PEER_TLS_ENABLED=true export CORE_PEER_LOCALMSPID="Org2MSP" export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/recipient@org2.example.com/msp export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt export CORE_PEER_ADDRESS=localhost:9051 ``` Using the Org2 terminal, the Org2 recipient user can retrieve their own account ID: ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"ClientAccountID","Args":[]}' ``` The function returns of recipient's client ID. The result shows that the subject and issuer is indeed the recipient user from Org2: ``` x509::/C=US/ST=North Carolina/O=Hyperledger/OU=client/CN=recipient::/C=UK/ST=Hampshire/L=Hursley/O=org2.example.com/CN=ca.org2.example.com ``` After the Org2 recipient provides their account ID to the minter, the minter can initiate a transfer from their account to the recipient's account. To transfer a non-fungible token, minter also needs to provide it's own account ID. Back in the Org1 terminal, the Org1 minter user can retrieve their own account ID: ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"ClientAccountID","Args":[]}' ``` The function returns of minter's client ID. The result shows that the subject and issuer is indeed the recipient user from Org1: ``` x509::/C=US/ST=North Carolina/O=Hyperledger/OU=client/CN=minter::/C=US/ST=North Carolina/L=Durham/O=org1.example.com/CN=ca.org1.example.com ``` After that, request the transfer of a non-fungible token `101` to the recipient account: ``` export MINTER="x509::/C=US/ST=North Carolina/O=Hyperledger/OU=client/CN=minter::/C=US/ST=North Carolina/L=Durham/O=org1.example.com/CN=ca.org1.example.com" export RECIPIENT="x509::/C=US/ST=North Carolina/O=Hyperledger/OU=client/CN=recipient::/C=UK/ST=Hampshire/L=Hursley/O=org2.example.com/CN=ca.org2.example.com" peer chaincode invoke $TARGET_TLS_OPTIONS -C mychannel -n token_erc721 -c '{"function":"TransferFrom","Args":["'"$MINTER"'", "'"$RECIPIENT"'","101"]}' ``` The `TransferFrom` function validates ownership of the given non-fungible token. It will then change the ownership of the non-fungible token from the current owner to the recipient. It will also debit the caller's account and credit the recipient's account. Note that the sample contract will automatically create an account with zero balance for the recipient, if one does not yet exist. While still in the Org1 terminal, let's request the minter's account balance again: ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"ClientAccountBalance","Args":[]}' ``` The function queries the balance of the account associated with the minter client ID and returns: ``` 0 ``` And then using the Org2 terminal, let's request the recipient's balance: ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"ClientAccountBalance","Args":[]}' ``` The function queries the balance of the account associated with the recipient client ID and returns: ``` 1 ``` While still in the Org2 terminal, let's check the current owner of the token. ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"OwnerOf","Args":["101"]}' ``` The function queries the owner of the non-fungible token with the token ID and returns: ``` x509::/C=US/ST=North Carolina/O=Hyperledger/OU=client/CN=recipient::/C=UK/ST=Hampshire/L=Hursley/O=org2.example.com/CN=ca.org2.example.com ``` Congratulations, you've transferred a non-fungible token! The Org2 recipient can now transfer the token to other registered users in the same manner. ## 3rd party transfers (Specific Token) This sample has another option, which allows an approved 3rd party operator to transfer a non-fungible token on behalf of the token owner. The owner appoves only one specific token to be transferred by the operator. This scenario demonstrates how to approve the operator and transfer a non-fungible token. In this scenario, you will approve the operator and transfer a specific non-fungible token as follows: - A minter has already created a non-fungible token according to the scenario above. - The same minter client uses the `Approve` function to give the permission for an operator client to transfer a non-fungible token which has a specific token ID on behalf of the minter. It is assumed that the operator has provided their client ID to the `Approve` caller out of band. - The operator client will then use the `TransferFrom` function to transfer the non-fungible token to the recipient's account on behalf of the minter. It is assumed that the recipient has provided their client ID to the `TransferFrom` caller out of band. ## Register identity for 3rd party operator You have already brought up the network and deployed the smart contract to the channel. We will use the same network and smart contract. We will use the Org1 CA to create the operator identity. Back in the Org1 terminal, you can register a new operator client identity using the `fabric-ca-client` tool: ``` fabric-ca-client register --caname ca-org1 --id.name operator --id.secret operatorpw --id.type client --tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem ``` You can now generate the identity certificates and MSP folder by providing the operator's enroll name and secret to the enroll command: ``` fabric-ca-client enroll -u https://operator:operatorpw@localhost:7054 --caname ca-org1 -M ${PWD}/organizations/peerOrganizations/org1.example.com/users/operator@org1.example.com/msp --tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem ``` Run the command below to copy the Node OU configuration file into the operator identity MSP folder. ``` cp ${PWD}/organizations/peerOrganizations/org1.example.com/msp/config.yaml ${PWD}/organizations/peerOrganizations/org1.example.com/users/operator@org1.example.com/msp/config.yaml ``` ## Approve an operator The minter intends to approve a non-fungible token to be transferred by the operator, but first the operator needs to provide their own client ID as the payment address. Open a 3rd terminal to represent the operator in Org1 and navigate to fabric-samples/test-network. Set the the environment variables for the Org1 operator user. ``` export PATH=${PWD}/../bin:${PWD}:$PATH export FABRIC_CFG_PATH=$PWD/../config/ export CORE_PEER_TLS_ENABLED=true export CORE_PEER_LOCALMSPID="Org1MSP" export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/operator@org1.example.com/msp export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt export CORE_PEER_ADDRESS=localhost:7051 export TARGET_TLS_OPTIONS="-o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt" ``` Now the Org1 operator can retrieve their own client ID: ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"ClientAccountID","Args":[]}' ``` The function returns of operator's client ID. The result shows that the subject and issuer is indeed the operator user from Org1: ``` x509::/C=US/ST=North Carolina/O=Hyperledger/OU=client/CN=operator::/C=US/ST=North Carolina/L=Durham/O=org1.example.com/CN=ca.org1.example.com ``` After the Org1 operator provides their client ID to the minter, the minter can approve an operator. Back in the Org1 minter terminal, issue a new non-fungible token with the token ID `102`. And then request the approval for the operator to transfer the token. ``` # Issue a new token peer chaincode invoke $TARGET_TLS_OPTIONS -C mychannel -n token_erc721 -c '{"function":"MintWithTokenURI","Args":["102", "https://example.com/nft102.json"]}' # The owner approves export OPERATOR="x509::/C=US/ST=North Carolina/O=Hyperledger/OU=client/CN=operator::/C=US/ST=North Carolina/L=Durham/O=org1.example.com/CN=ca.org1.example.com" peer chaincode invoke $TARGET_TLS_OPTIONS -C mychannel -n token_erc721 -c '{"function":"Approve","Args":["'"$OPERATOR"'", "102"]}' ``` The approve function specified that the operator client can transfer the non-fungible token with the given token ID on behalf of the minter. We can check the operator client's approval by calling the `GetApproved` function. Let's request the operator's approval from the Org1 minter terminal. ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"GetApproved","Args":["102"]}' ``` The function queries the approval associated with the operator client ID and returns: ``` x509::/C=US/ST=North Carolina/O=Hyperledger/OU=client/CN=operator::/C=US/ST=North Carolina/L=Durham/O=org1.example.com/CN=ca.org1.example.com ``` ## Transfer a non-fungible token The operator intends to transfer a non-fungible token to the Org2 recipient on behalf of the minter. The operator has already got the minter client Id and the recipient client ID. Back in the 3rd operator terminal, request the transfer of a non-fungible token `102` to the recipient account: ``` export MINTER="x509::/C=US/ST=North Carolina/O=Hyperledger/OU=client/CN=minter::/C=US/ST=North Carolina/L=Durham/O=org1.example.com/CN=ca.org1.example.com" export RECIPIENT="x509::/C=US/ST=North Carolina/O=Hyperledger/OU=client/CN=recipient::/C=UK/ST=Hampshire/L=Hursley/O=org2.example.com/CN=ca.org2.example.com" peer chaincode invoke $TARGET_TLS_OPTIONS -C mychannel -n token_erc721 -c '{"function":"TransferFrom","Args":[ "'"$MINTER"'", "'"$RECIPIENT"'", "102"]}' ``` The `TransferFrom` function validates that the account associated with the calling client ID has the permission to transfer the given token on behalf of the current owner. It will then change the ownership of the non-fungible token from the current owner to the recipient. It will also debit the previous owner's account and credit the recipient's account. It will also remove the operator's permission for this non-fungible token approved by the minter. Note that the sample contract will automatically create an account with zero balance for the recipient, if one does not yet exist. While still in the 3rd operator terminal for the operator, let's request the minter's account balance again: ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"BalanceOf","Args":["'"$MINTER"'"]}' ``` The function queries the balance of the account associated with the minter client ID and returns: ``` 0 ``` And then, let's check the current owner of the token. ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"OwnerOf","Args":["102"]}' ``` The function queries the owner of the non-fungible token with the token ID and returns: ``` x509::/C=US/ST=North Carolina/O=Hyperledger/OU=client/CN=recipient::/C=UK/ST=Hampshire/L=Hursley/O=org2.example.com/CN=ca.org2.example.com ``` While still in the 3rd operator terminal for the operator, let's request the operator's approval from the minter again. ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"GetApproved","Args":["102"]}' ``` The function queries the approval associated with the operator client ID and returns no value. And then using the Org2 terminal, let's request the recipient's balance: ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"ClientAccountBalance","Args":[]}' ``` The function queries the balance of the account associated with the recipient client ID and returns: ``` 2 ``` Congratulations, you've transferred a non-fungible token! The Org2 recipient can now transfer tokens to other registered users in the same manner. ## 3rd party transfers (All tokens) This sample has another option, which allows an approved 3rd party operator to transfer all non-fungible tokens on behalf of the token owner. The owner approves all tokens to be transferred by the operator. This scenario demonstrates how to approve the operator and transfer non-fungible tokens. In this scenario, you will approve the operator and transfer a non-fungible token as follows: - A minter has already created a non-fungible token according to the scenario above. - The same minter client uses the `SetApprovalForAll` function to give the permission for an operator client to transfer all non-fungible tokens on behalf of the minter. It is assumed that the operator has provided their client ID to the `SetApprovalForAll` caller out of band. - The operator client will then use the `TransferFrom` function to transfer the non-fungible token to the recipient's account on behalf of the minter. It is assumed that the recipient has provided their client ID to the `TransferFrom` caller out of band. ## Approve an operator Request the approval for the operator to transfer the token. we assume that the minter has already got the operator client ID as the payment address. Back in the Org1 minter terminal, request the approval for the operator to transfer all tokens on behalf of the original owner. ``` peer chaincode invoke $TARGET_TLS_OPTIONS -C mychannel -n token_erc721 -c '{"function":"SetApprovalForAll","Args":["'"$OPERATOR"'", "true"]}' ``` The `SetApprovalForAll` function specified that the operator client can transfer any non-fungible tokens on behalf of the minter. We can check the operator client's approval by calling the `IsApprovedForAll` function. Let's request the operator's approval from the Org1 minter terminal. ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"IsApprovedForAll","Args":["'"$MINTER"'", "'"$OPERATOR"'"]}' ``` The function queries the approval associated with the operator client ID and returns: ``` true ``` ## Transfer a non-fungible token The operator intends to transfer a non-fungible token to the Org2 recipient on behalf of the minter. The operator has already got the minter client Id and the recipient client ID. Still in the Org1 minter terminal, issue a new non-fungible token with the token ID `103`. ``` peer chaincode invoke $TARGET_TLS_OPTIONS -C mychannel -n token_erc721 -c '{"function":"MintWithTokenURI","Args":["103", "https://example.com/nft103.json"]}' ``` Back in the 3rd operator terminal, request the transfer of a non-fungible token `103` to the recipient account: ``` peer chaincode invoke $TARGET_TLS_OPTIONS -C mychannel -n token_erc721 -c '{"function":"TransferFrom","Args":[ "'"$MINTER"'", "'"$RECIPIENT"'", "103"]}' ``` The `TransferFrom` function validates that the account associated with the calling client ID has the permission to transfer tokens on behalf of the current owner. It will then change the ownership of the non-fungible token and update balances like the other options. While still in the 3rd operator terminal for the operator, let's request the minter's account balance again: ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"BalanceOf","Args":["'"$MINTER"'"]}' ``` The function queries the balance of the account associated with the minter client ID and returns: ``` 0 ``` And then, let's check the current owner of the token. ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"OwnerOf","Args":["103"]}' ``` The function queries the owner of the non-fungible token with the token ID and returns: ``` x509::/C=US/ST=North Carolina/O=Hyperledger/OU=client/CN=recipient::/C=UK/ST=Hampshire/L=Hursley/O=org2.example.com/CN=ca.org2.example.com ``` And then using the Org2 terminal, let's request the recipient's balance: ``` peer chaincode query -C mychannel -n token_erc721 -c '{"function":"ClientAccountBalance","Args":[]}' ``` The function queries the balance of the account associated with the recipient client ID and returns: ``` 3 ``` Congratulations, you've transferred a non-fungible token! The Org2 recipient can now transfer tokens to other registered users in the same manner. ## Clean up When you are finished, you can bring down the test network. The command will remove all the nodes of the test network, and delete any ledger data that you created: ``` ./network.sh down ``` Signed-off-by: renjithkn@gmail.com <renjithkn@gmail.com> Signed-off-by: renjithpta <renjithkn@gmail.com>

Signed-off-by: renjithpta <renjithkn@gmail.com>

renjithpta · 2022-04-01T16:27:41Z

I have updated the files to include the review suggestions

renjithpta · 2022-04-04T05:55:33Z

One final comment on the review of the Java source. If your code introduces the use of final modifiers, please ensure that either ALL of the immutable variables in the scope of the routines are marked as final, or NONE of them are declared as final.

Thanks @renjithpta !

renjithpta · 2022-04-04T10:14:04Z

One final comment on the review of the Java source. If your code introduces the use of final modifiers, please ensure that either ALL of the immutable variables in the scope of the routines are marked as final, or NONE of them are declared as final.

Thanks @renjithpta !

I have modified the code as per the review suggestion

jkneubuh

I had a chance to run the chaincode this afternoon. It is looking pretty good! I have a couple of additional change requests, based on running through the erc721 README guide:

There are still a lot of empty newlines between Javadoc method comments and methods, as well as trailing newlines at the end of the method declarations.
Please change the permissions of docker/docker-entrypoint.sh to 0x755 to allow for execution within the Docker container.
In Approval.java, do not use the (deprecated) new Boolean(boolean) constructor, but prefer the Boolean.valueOf(json.getBoolean("approved")) method call (line ~115)
don't forget to add exec to the java targets in docker-entrypoint.sh. This is really important for sending ^C / KILL signals to the container.
Align the contract method names with the conventions established in the contract-go and contract-typescript. When I went through the README / guide, I noticed that the Java contract uses the typical camelCaseConvention(), whereas the golang and typescript examples use the StrongCamelCaseConvention() with a leading upcast character in the contract function names. I found a few of these - please make a pass over all the contract function names and align them with the other samples for consistency. e.g. :

mintWithTokenURI() --> MintWithTokenURI()
getClientAccountBalance() --> ClientAccountBalance()
ownerOf() --> OwnerOf()
getClientAccountId() --> `ClientAccountID()'
etc. ...

This is looking great! Apologies for the long delay getting queued up into the PR review cycle.

Thanks @renjithpta !

jkneubuh · 2022-03-31T19:24:12Z

token-erc-721/chaincode-java/docker/docker-entrypoint.sh

+: ${DEBUG:="false"}
+
+if [ "${DEBUG,,}" = "true" ]; then
+   java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=0.0.0.0:8000 -jar /chaincode.jar


please add an exec java, here and below. Otherwise the signal handlers are not set up correctly, and the chaincode running in the container will not always shut down cleanly from a ^C / KILL.

jkneubuh · 2022-03-31T19:24:53Z

...c-721/chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/ContractErrors.java

+    TOKEN_NOT_FOUND,
+    TOKEN_ALREADY_EXITS,
+    NO_OWNER_ASSIGNED,
+    UNOTHERIZED_SENDER,


UNAUTHORIZED_SENDER

jkneubuh · 2022-03-31T19:25:43Z

...-721/chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/models/Approval.java

+  */
+  public Approval() {
+    super();
+


Please double-check the newlines in the source. No empty lines at the end of the routine, and at least one empty line between method declarations.

jkneubuh · 2022-03-31T19:26:01Z

...-721/chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/models/Approval.java

+   * 
+   * @return
+   */
+


jkneubuh · 2022-03-31T19:26:26Z

...-721/chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/models/Approval.java

+   */
+  public static Approval fromBytes(final byte[] bytes) {
+    return new Genson().deserialize(new String(bytes, UTF_8), Approval.class);
+


no newlines before closing '}' of a method and class

jkneubuh · 2022-03-31T19:28:01Z

...n-erc-721/chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/models/NFT.java

+   * 
+   * @param tokenId
+   */
+


jkneubuh · 2022-03-31T19:29:15Z

...-721/chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/models/Transfer.java

+   * @param to
+   * @param tokenId
+   */
+


Last comment on the \n ..... Please make a pass at the source and make sure there are no empty \n between comments and method declarations. No \n at the end of method body text, or between the last method in the class and the closing } for the class.

jkneubuh · 2022-03-31T19:31:50Z

.../chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/ERC721TokenContract.java

+    ChaincodeStub stub = ctx.getStub();
+    CompositeKey balanceKey = stub.createCompositeKey(ContractConstants.BALANCE.getValue(), owner);
+    QueryResultsIterator<KeyValue> results = stub.getStateByPartialCompositeKey(balanceKey);
+    return StreamSupport.stream(results.spliterator(), false).count();


For clarity here can you please use a for loop iterator and loop counter to count the number of composite keys. I understand this is the same computation, but it does add to the readability and aligns with the golang implementation:

balance := 0 for iterator.HasNext() { _, err := iterator.Next() if err != nil { return 0 } balance++ } return balance

jkneubuh · 2022-03-31T19:32:14Z

.../chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/ERC721TokenContract.java

+
+      final Approval approval = Approval.fromJSONString(approvalJson);
+      return approval.isApproved();
+


jkneubuh · 2022-03-31T19:33:13Z

.../chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/ERC721TokenContract.java

+    ChaincodeStub stub = ctx.getStub();
+    CompositeKey nftKey = stub.createCompositeKey(ContractConstants.NFT.getValue());
+    QueryResultsIterator<KeyValue> iterator = stub.getStateByPartialCompositeKey(nftKey);
+    return StreamSupport.stream(iterator.spliterator(), false).count();


As above, I understand the stream support.stream().count() is equivalent, but would prefer to see an explicit loop + counter in scope for clarity.

jkneubuh · 2022-04-06T15:30:15Z

Hi @renjithpta

Something went horribly wrong with the last force push up to git. I'm afraid this PR branch merge is no longer viable.... the last commit now shows 203 files modified in the PR.

Can you please set up a new branch on your development fork for this project, and:

pull the main/latest from fabric-samples
re-add / commit the chaincode-java sample source files
Create a new PR / merge request.

Let's get this project landed. It is a really good example and demonstration of ERC-721.

renjithpta requested a review from a team as a code owner March 6, 2022 04:53

renjithpta changed the title ~~Java chaincode implementation for ERC72 standard token.~~ Java chaincode implementation for ERC721 standard token. Mar 9, 2022

timo-kang reviewed Mar 28, 2022

View reviewed changes

...n-erc-721/chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/models/NFT.java Show resolved Hide resolved

timo-kang reviewed Mar 28, 2022

View reviewed changes

.../chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/ERC721TokenContract.java Show resolved Hide resolved

timo-kang reviewed Mar 28, 2022

View reviewed changes

...n-erc-721/chaincode-java/src/main/java/org/hyperledger/fabric/samples/erc721/models/NFT.java Show resolved Hide resolved

jkneubuh requested changes Mar 31, 2022

View reviewed changes

renjithpta and others added 7 commits April 1, 2022 19:12

Signed-off-by: Renjith K N <renjithkn@gmail.com>.

c712d93

ERC 721 implementation of java chaincode. Signed-off-by: renjithkn@gmail.com <renjithkn@gmail.com> Signed-off-by: renjithpta <renjithkn@gmail.com>

Signed-off-by: Renjith K N <renjithkn@gmail.com>.

3873cf7

ERC 721 implementation of java chaincode. Signed-off-by: renjithkn@gmail.com <renjithkn@gmail.com> Signed-off-by: renjithpta <renjithkn@gmail.com>

Signed-off-by:Renjith K N <renjithkn@gmail.com>

62b4131

Signed-off-by: FIRST_NAME LAST_NAME <renjithkn@gamil.com> Signed-off-by: renjithpta <renjithkn@gmail.com>

Signed-off-by:Renjith K N <renjithkn@gmail.com>

c31137e

Signed-off-by: FIRST_NAME LAST_NAME <renjithkn@gamil.com> Signed-off-by: renjithpta <renjithkn@gmail.com>

Signed-off-by:Renjith KN <renjithkn@gmail.com>

b20ad95

Signed-off-by: renjithpta <renjithkn@gmail.com>

ERC721 review comments

808fe1f

Signed-off-by: renjithpta <renjithkn@gmail.com>

renjithpta requested a review from jkneubuh April 1, 2022 14:56

renjithpta closed this Apr 4, 2022

renjithpta reopened this Apr 4, 2022

jkneubuh requested changes Apr 5, 2022

View reviewed changes

renjithpta closed this Apr 6, 2022

jkneubuh mentioned this pull request Apr 8, 2022

Java erc721 token standard chaincode implementation. #709

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Java chaincode implementation for ERC721 standard token. #670

Java chaincode implementation for ERC721 standard token. #670

renjithpta commented Mar 6, 2022

jkneubuh left a comment

jkneubuh commented Mar 31, 2022

renjithpta commented Apr 1, 2022

renjithpta commented Apr 4, 2022

renjithpta commented Apr 4, 2022

jkneubuh left a comment

jkneubuh Mar 31, 2022

jkneubuh Mar 31, 2022

jkneubuh Mar 31, 2022

jkneubuh Mar 31, 2022

jkneubuh Mar 31, 2022

jkneubuh Mar 31, 2022

jkneubuh Mar 31, 2022

jkneubuh Mar 31, 2022

jkneubuh Mar 31, 2022

jkneubuh Mar 31, 2022

jkneubuh commented Apr 6, 2022


		final Approval approval = Approval.fromJSONString(approvalJson);
		return approval.isApproved();

Java chaincode implementation for ERC721 standard token. #670

Java chaincode implementation for ERC721 standard token. #670

Conversation

renjithpta commented Mar 6, 2022

jkneubuh left a comment

Choose a reason for hiding this comment

jkneubuh commented Mar 31, 2022

renjithpta commented Apr 1, 2022

renjithpta commented Apr 4, 2022

renjithpta commented Apr 4, 2022

jkneubuh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkneubuh commented Apr 6, 2022