Capstone: Real Estate Marketplace Project FAQ — Udacity Blockchain

Alvaro Andres Pinzon Cortes
10 min readMar 31, 2019

Walkthrough Capstone Real Estate Marketplace — Udacity

https://youtu.be/aTtiIWfl910

  1. I have created the Verifier.sol contract and moved to the contract folder. How I want to implement the TestSquareVerifier.js scrit test but I dont know how I have to call the verifyTx function in Verifier. In the boilerplate is mention that we have to use the proof.json file to test a positive verification. But How I have to call verifyTx function with the proof.json file?

To call the verifyTx function in Verifier do this:

  • Copy the proof JSON in the TestSquareVerifier.js and store it on a variable
  • Call the function verifyTx from Verifier and pass to it the 9 parameters that it requires

2. Ther is something that I dont understand 100%. Theorethicaly we have to use the Verifier contract to proof that a user is the owner of a house for example. With the square.code that we have used I dont understand how we can proof that. Because we are only checking if a * a == b. When we use our custom ERC721 token contract in OpenSea, do we have to use the current Verifier contract also? Or for the OpenSea part we dont need it?

The contract that we use in OpenSea is the ERC721, NOT the Verifier. The Verifier is just used to verify that the proof is valid and if it is valid then we can mint another token representing another property. To mint you interact with the contract and then OpenSea automatically detects that a new token was minted and displays it in the store

3. I am now in the SolnSquareVerifier.sol file. The first requirement is to define a contract call to the zokrates generated solidity contract <Verifier>. What exactly are you meaning here? Have I to create a contract that inherit from Verifier?

You need to do something similar to what you did on the FlightSurety Project

  • Create an instance of the Verifier contract inside the SolnSquareVerifier contract
  • And outside of the SolnSquareVerifier contract create a contract interface for the Verifier contract to be able to call its functions
pragma solidity >=0.4.21 <0.6.0;import './ERC721Mintable.sol';// TODO define a contract call to the zokrates generated solidity contract Verifier.sol// TODO define another contract named SolnSquareVerifier that inherits ERC721Mintablecontract SolnSquareVerifier is UdacityRealStateTitle {constructor(address verifierAddress, string memory name, string memory symbol) UdacityRealStateTitle(name, symbol) public 
{
verifierContract = Verifier(verifierAddress);
}
}contract Verifier {}

4. Hi, can I use angular for my frontend?

  • OpenSea is going to be the website where we are going to sell and manage our real state properties. You should not create a front-end to sell, manage and market your real state properties
  • On the other hand, you could create a front-end to mint the properties and to add the solution of the proof of ownership. It is not required to do so, but it could be a cool extra feature

5. Hi, I’m having trouble with the Capstone project. Unfortunately I can’t generate the files with ZoKrates. I get an „illegal instruction“ error at the “zokrates setup”. I have tested this on Windows as well as on Mac. The problem is also described here, but without a solution: https://github.com/Zokrates/ZoKrates/issues/275

Found a possible solution. I tested different versions of ZoKrates (in the Docker). With version 0.3.0 it finally worked. I.e. instead of:docker run -v <path to your project folder>:/home/zokrates/code -ti zokrates/zokrates /bin/bashuse the following:docker run -v <path to your project folder>:/home/zokrates/code -ti zokrates/zokrates:0.3.0 /bin/bashThat's how it worked for me.

Answer from the student Tobias S

6. Hi, I’m not quite sure what is meant by “solution” in the SolnSquareVerifier. If I understand that correctly, I have to pass the correct “proof” generated by ZoKrates to the “mint” function of the “SolnSquareVerifier” and check it. But what exactly is done with the “Solutions”? That’s not clear to me from the comments and I didn’t find it anywhere else.

The solution refers to the set of variables that you pass to verifyTx. A user can submit different solutions that satisfy the zokrates check. In this case, a root and its square (e.g. 3 and 9) will generate a proof. To store it in the mapping or array, it does not have to be separate variables. You can just hash it if all you want is to check if it is unique. You can use keccak256 for that. You can to create a unique hash for each solution. This tutorial can show you how.

The idea is store a particular solution and that we can verify if a particular solution was already used. For this it useful to make that you can search for every solution submitted by their hash

Answer from the mentor Chris F

7. I‘m just confused that in the TODOs (SolnSquareVerifier.sol) says “TODO define an array of the above struct” AND “TODO define a mapping to store unique solutions submitted”. Actually only one of them is used here, right?

There is no need to use the an array to store the solutions if you use a mapping to store unique solutions submitted. Just use the mapping.

The idea is store a particular solution and that we can verify if a particular solution was already used. For this it useful to make that you can search for every solution submitted by their hash. This tutorial can show you how.

8. Just to verify a detail, one of the project requirements states to mint 10 tokens (after deployment to rinkeby). If I undestand that correctly, I should run zokrates 10 times to get 10 different proofs, to use while minting. correct?

You should run zokrates 10 times to get 10 different proofs, correct

9. Hi, question on the requirement to create a Pausable contract that inherits from the Ownable contract. Would it be acceptable to go the open-zeppelin route, and modify inheritance to following contracts?

Most of the functions in the ERC721Mintable file is inspired by OpenZeppelin. You can definitely use that as reference and copy the code from OpenZeppelin to this file. I advise that you just follow the comments here to make the process more straightforward.

Answer from the mentor Chris F

You can use the files from OpenZeppelin. There is no problem

10. Why in square.code the computation is to verify a number and its square?

The numbers to input into square.code are like a password that only the owner of the property knows and that we use zkSNARKS to prove that we know the password that only the real owner of the property knows. We use a number and its square as the “mistery computation” as a simplification for this project. In a real scenario we could do a proof of knowledge of a hash preimage (document, passwords, etc..). This tutorial is useful for understanding this better https://zokrates.github.io/sha256example.html

11. I have a problem with the verifier zokrates generates. its solidity version is old. so I upgrade it to 0.5. but then it couldn’t be compiled due to type errors. Is there a way to choose the version of the exported verifier?

You need to adjust the Verifier.sol so that it complies with solidity 0.5. Please work on all the changes showed by the compiler

12. Hi there — a quick question — for the Zokrates implementation — do we just use the current logic in the file — i.e. verifying a*a == b or do we need to come up with a new logic?

Yes it would be simpler if you use that logic. If you decide to implement another way, do make sure that you mark it in the Student Notes and README so it won’t get flagged by the reviewer.

Answer from the awesome mentor Chris F.

You can just use the current logic in the file — i.e. verifying a*a == b

As a reminder that logic inside the square.code is what in the videos was called the “mystery computation” that proves are knowledge of something.

For this project, for simplicity we use as “mystery computation” a*a == b. A more realistic “mystery computation” would be to check if a document that only the owner of the property has, is the preimage for a hash. When I say preimage I mean the input to a hashing function. Also, another realistic “mystery computation” would be to check if a password that only the owner of the property has, is the preimage for a hash

13. However, I do not completely understand the last segment where we create our own customERC721 contract that inherits everything. More specifically, do we need to pass in values in its own constructor, as such that it is passed to the constructor of the Metadata contract? And, the mint function, it says we need to set also tokenURI as argument but if we already have the baseTokenURI defined, and have the tokenId, don’t we then just use setTokenURI to generate it instead of having to pass it in?

  • Related with the mint function. That function only needs this parameters: mint(address to, uint256 tokenId), because we already have the baseTokenURI defined
  • For the CustomERC721Token you need to pass parameters to its constructor but also to the constructor of the contract ERC721Metadata that it inherited from

14. I am currently trying to write the SolnSquareVerifier contract. But I am a bit unsure regarding the whole idea behind it. We have the ERC721MintableCustomer contract with the Token functionality. We have the Verifier contract with the dummy verifyer functionality (focused on showing we have the square). Does the SolnSquare inherit from both, or only from the CustomERC721, and then imports and calls the Verifier contract using its specific address?

SolnSquare inherits from CustomERC721

Verifier is a separate contract that you need to interact with.

Please take a look also at question 3 in this FAQ.

15. Sorry, but I don’t understad what I have to do in SolnSquareVerifier.sol

// TODO define a solutions struct that can hold an index & an address

what exactly the index and the address refer to? I have created such structure, what is the purpose of this?

The idea of that struct is to store information related to a solution that was submitted.

  • The address from the struct is the address of the the person that submitted that solution
  • The index is an identifier that represents the order of the solution. If it is the first solution submitted to the system, then its index is 1. If it is the eighth solution submitted to the system, then its index is 8.

Optionally you could also store the hash of the solution. Also, I want to mention that every solution MUST be unique, the CAN’T be two solutions that are equal. To verify that you can hash the solutions and use the hash as a key for a mapping of solutions

16. OpenSea throws this error “Looks like your contract is not ERC721 compliant.”

Please first try to take a look at this link https://knowledge.udacity.com/questions/41082

Please try to follow the instructions in this tutorial from OpenSea to verify that your contract is correct https://docs.opensea.io/docs/1-structuring-your-smart-contract

🎥 OpenSea: Looks like your contract is not ERC721 compliant https://youtu.be/xvyqdOls7QM

Answer from the Awesome mentor Alvaro Andres Pinzon Cortes

I have a feeling that you named your getters for name, symbol, and baseTokenURIdifferently. Please name the public getters as name(), symbol(), and baseTokenURI(). Actually, only name and symbol is required for that naming convention but just include the baseTokenURI anyway for uniformity. This is required for ERC721 compliance. You can even see this in action in Etherscan. If you don't name the functions as such, the token tracker will not be activated and the tokens will not be recognized as ERC721

Answer from the Awesome mentor Chris F

17. where do i start with Opensea? Just go through opensea docs?

Yes, I recommend that you follow the instructions in the OpenSea docs from step 1 to 4 of this tutorial https://docs.opensea.io/docs/1-structuring-your-smart-contract:

1. Structuring your smart contract

2. Adding metadata

3. Viewing your items on OpenSea

4. Create your storefront

This is a good tutorial that I made to show you how to list token in OpenSea https://youtu.be/xvyqdOls7QM

18. How to mint tokens?

You have these options

  1. Use this javascript code https://github.com/andresaaap/mint-ntf or this https://docs.alchemy.com/alchemy/tutorials/how-to-create-an-nft/how-to-mint-an-nft-with-ethers
  2. Use MyEtherWallet to interact with the contract https://vintage.myetherwallet.com/#contracts
  3. Use Rinkeby etherscan to interact with the contract https://rinkeby.etherscan.io
  4. Use the remix IDE that offer an easy way to interact with contracts. You need to deploy your contract using the remix IDE. Then, it will give you an UI to interact with the contract.

This is a tutorial in YouTube https://youtu.be/8MChn-NJJB0

19. Can someone help me understand what this requirement (contracts/ERC721Mintable.sol TODO) is asking for: “1) Pass in appropriate values for the inherited ERC721Metadata contract”? Do we need to call the ERC721Metadata contract somehow and pass in values? If so how and what values exactly?

  • CustomERC721Token inherits from ERC721Metadata, therefore, CustomERC721Token needs the constructor parameters that ERC721Metadata needs
  • One way to do it is like this:
constructor(string memory name, string memory symbol) ERC721Metadata(name, symbol, "https://s3-us-west-2.amazonaws.com/udacity-blockchain/capstone/") public {}

20. I’m on the last project just confused with SolSquareVerifier.sol. I didn’t understand the flow of the and specially the add solution How is this function called and how is the SquareVerifier sol will be used and how will the proof will be passed to it. from where will one pass the values to the verifyTx

The functional requirement is to mint a token in SolSquareVerifier.sol

The steps are these:

  1. The user executes the mint function and inputs to it the the necessary parameters to mint and proof
  2. Verify that the proof was not used previously
  3. Verify that the proof is valid
  4. Execute the addSolution function to store the solution to make sure that this solution can’t be used in the future
  5. Mint the token

21. How to run Zokrates for the project?

I made this video to help you

https://youtu.be/0pY1Sd7aDjM

😀👍

--

--