diff --git a/README.md b/README.md index 0ec2117..8c62573 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -## TRON Core Devs Meetings +## TRON Core Devs Meetings and SR Meetings ### Purpose The TRON core devs meeting is a technical meeting intended to bring together all the TRON developers who play major roles in determining the direction of the TRON protocol. TRON developers provide updates to their projects, discuss various [TIPs](https://github.com/tronprotocol/tips) to improve the protocol, and support each other. @@ -14,7 +14,10 @@ The TRON core devs meeting is a technical meeting intended to bring together all 5 | Mon, 13 Apr, 2020 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/6) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2005.md) | [video](https://www.youtube.com/watch?v=GAi-I2MlGgM&t=11s) 6 | Thur, 30 Apr, 2020 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/7) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2006.md) | [video](https://www.youtube.com/watch?v=xXY7kf4tV-Q&feature=youtu.be) 7 | Tues, 16 Jun, 2020 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/8) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2007.md) | [video](https://www.youtube.com/watch?v=fY6sG285ee4) - + 8 | Tues, 11 Aug, 2020 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/11) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2008.md) | [video](https://youtu.be/EX63qtcvNAc) + 9 | Thu, 24 Sep, 2020 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/14) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2009.md) | [video](https://youtu.be/jq_tvSXnXss) + + ### Who Can Attend These meetings are held by TRON core devs. The following groups are invited to attend the meetings: diff --git a/TRON Core Devs Meetings/Meeting 08.md b/TRON Core Devs Meetings/Meeting 08.md new file mode 100644 index 0000000..0e91a14 --- /dev/null +++ b/TRON Core Devs Meetings/Meeting 08.md @@ -0,0 +1,132 @@ +# TRON Core Devs Meeting 08 Notes + +### Meeting Date/Time: Tuesday, Aug 11, 2020 09:00 AM UTC + +### Meeting Duration: 1 hour + +### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/11) + +### [Audio/Video of the meeting](https://youtu.be/EX63qtcvNAc) + +# Agenda + +- Latest update of java-tron +- TRON DPOS introduction: TIP-62 +- New Consensus TPOS introduction. TIP-64 +- Future plan of TPOS. + +## Latest update of java-tron + +- Sakary + - Mainly there are two contents this time. One is the releasing of the Great Voyage 4.0.1. We’ve optimized the upgrade mechanism of java-Tron that 22 super representatives are required to upgrade to the new version instead of 27. I believe this will lead to more decentralized governance. + The other is we launched the #40 voting request today for proposal 39. If proposal 39 comes to effect, zero-knowledge proof-verification functions will be supported in TVM, also, shielded TRC20 contract will be supported in TRON network. This will provide better privacy as users can hide their transaction amount, source and destination address. + +## TIP62 +- Xing + - Today I will give a speech about Tron Consensus. Welcome everyone to join this meeting. I will break today's topic into 2 parts, the first part I will talk about the old Tron consensus, the next part, I will talk about the new Tron consensus, which called TPOS. + - Let's get started with the old consensus. First of all, what is the consensus in blockchain, mostly we want to keep the consistency of the transaction, which means, once a transaction was made, it needs to be validated and approved by the whole network so that we know the value of this token is approved by everybody since we do not need a bank, it is decentralized. + - Let's see some popular consensus in the blockchain. first one, POW, proof of work. it is widely used in bitcoin and Etherum, mostly POW is like to proof capability, they do a `while` loop to find a valid hash value which starts with a certain amount of 0. The amount of 0 depends on the network, it might be very long or very short. for example, if the network requires the first 10 characters of the hash value are '0', it might take a long time to do calculations. This is how the POW works. The next is DPOS and POS, I will give more detail in the coming slides. the last is PBFT, also widely used in blockchain. + - The old consensus in Tron is introduced in TIP 62, feel free to check it on GitHub and leave comments there if you got any questions. How does TRON DPOS work? it has 4 stages, the first one is the vote, users need to vote for candidates. the second one is producing block, the third is to confirm the produced block, the last one is the reward, users and SR will both get the reward, everybody is happy. + - Let's get started with the first stage, Vote, we have 3 processes need to do, first, users need to freeze their TRX, after that they can start to vote, users can go to the tronscan to see the SR candidate list, and select SR candidate and do the vote. In the final step, the system will calculate the number of the votes and chose the Top 27 as SR from the SR candidates list. and these 27 SRs got the right of producing block. + - The next stage is producing block, firstly SR needs to check turn, SR will start to produce block if it is its turn, the last step is broadcast the block. let's take a look at this picture, the turn is very important, first, we need to get the vote order from the voting stage, all 27 SRs are listed based on their numbers of votes. the first SR gets the biggest number of votes. How do we map the SR vote order to the time slot index? The first time slot will be the SR with the highest number of votes, and all the way to the 27 SR. Each slot is 3 seconds, means in the first 3 seconds, it is the first SR's turn to produce the block. (SR with the highest votes), and the next time slot is for the second-highest voted SR, and all the way to the 27 SR. so what happens to the 28th time slot, 28 mod loop 27, means No. 28 slot will be the first highest votes SR's turn, we will always do this kind of circle, any question? + +- Philip + - I have a question, how do you select who among the 27 SR to produce the block? + +- Xing + - We have maintenance period which marked in green, in this period, we collect the vote from users, for example, we have 100 SR candidates, and a lot of users they are voting for SR candidates, in the maintenance period, we collect all votes and sorted the SR by the number of votes. The top 27 will be SR. + + - Philip + - I got it, once you are present the 27, which SR will produce block? + +- xing + - They produce block based on the order and time slot, we have 27 SR, from number 1 to number 27, also we have time slots, each slot is 3 seconds, SR check turn based on the time, for example, the index of 9th seconds is 3 in one Epoch, SR will compare the slot index with SR rank, if slot index = Rank, then it is current SR's turn. then start to produce a block. + +- Philip + - What you are saying is that each producer gets their turn within 27, each will get turn and wait to product block. + +- Xing + - Yes. I cannot do whiteboard stuff, if I can I will give you some use case about it. you can understand it like this, in the first 3 seconds, number 1 SR will produce the block, in the next 3 seconds, number 2 SR will produce the block. all the way to 27 SR. + + - One thing I need to mention here is the red box, the red color means empty. sometimes something might go wrong, SR cannot product block, it will get empty, means nothing got from this time slot. + - In the producing stage, we will do package, the transaction validation, after that we will check the fork status and decide whether to switch a fork. finally, we sign the block and update the local database. + - Lastly, we will do confirm, basically it is majority consensus. here, yellow means the solidate status， red means unconfirmed block, here you can see a sliding window, the window includes 19 block, the sliding window will move one by one. if a fork happened, will start a new window after forked. + +- Vinod + - I have a question, take an example, you are the 27 SR, setting with 200M votes, then we have Benson, who setting with 219M votes, however, he is on 28. That is why he is not eligible to produce a block. however Benson receive 10M vote from someone, pushing him to 27 place, and robing you from 27 to 28, might be Benson was not ready with his equipment to produce a block, in that case, what will happen because now Benson has moved to 27 but he is not ready to produce blocks. will it be 26 SRs producing blocks? + +- Xing + - We have the definition of an epoch, one epoch has 6 hours, we select SR every 6 hours, so after 6 hours Benson will start to produce block if he is in 17. within 6 hours, the SR cannot be changed. + +- Vinod + - I do agree, what I am trying to ask is what if Xing is not able to move from 28 back to 27 in those 6 hours, will we end up like, for next 8-10 hours, we will get block produced by 26 SRs other than 27 in total. so it is just a hypothetical situation that I am asking. It might happen, it might not happen anyway. + +- Xing + - I am a little confused about your question, is your question about voting stuff, right? + +- Vinod + - yes, after receiving votes, say it is now 8 hours since he has received those 10M extra votes and person who dropped from 27 to 28 haven't received any new votes in those more than 6 hours, the 6 hours cycle has passed, and now you need to get the SR in the list +- Xing + - Once we selected the SR, we did not change in 6 hours. whatever you do, maybe network issue or something goes wrong, staying the same. + + - I would like to mention why do we chose 2/3+1, not 1/2+1. if we choose 1/2+1, it is also majority consensus, but in this way, we can give an example, we have 11 nodes, 5 good, 5 bad, and one is down. in this case, we cannot reach an agreement. we cannot reach consensus. this is why we choose 2/3+1 as 3 is an odd number. + - What happens if there are forks. in the old Tron consensus, we always choose a longer chain as the main chain. it means every time you just check the size of the chain in the local database, if you find any longer chain, you just switch and then broadcast. + - Now we will talk about reward, in Tron consensus, we have a very good policy for users and witness, users who voted SR and SRs who produced block will both get the reward. + + - However, there are a lot of limitations for old Tron consensus, and we started to do some optimization. In old consensus, I always take too much time to confirm a transaction, we need one minute to confirm a transaction. from the user point of view waiting for 1 min is not tolerant, that is why we need optimization. at the same time for exchange, DAPP, especially real-time transactions like gambling we need to fast the chain. for other projects like the cross-chain, we also need better consensus to support cross-chain. After the study, we choose to introduce PBFT into the Tron consensus. we did some modifications on PBFT compares to the original PBFT. + +## TIP64 +- Xing + - Now let us start the second part, TPOS means Tron Consensus Algorithm. it is part of PBFT with DPOS. Please check TICP1 in our GitHub for more info if you are interested. Let's start with "Role", for PBFT, we have 3 roles, Primary replicas, replicas, Client. For TPOS, we only have Verifier, SR, and fullnode. + - For phase, in PBFT, we have 5 phases, request, pre-prepare, prepare, commit, reply. while in TPOS, we only have 3 phases, Block broadcast(equals to pre-prepare), Vote (equals to Prepare), Verify(equals to commit). + - This is how PBFT works the client will send the request to primary replica, once the primary replica received the quest, it will broadcast the message to the whole network, after other replicas received the message from the primary replica, they will multicast prepare message to the network. again, at the prepare phase, once replicas received messages from pre-prepare phase, they will start to generate the commit messages, and multicast the commit messages. Similarly, replicas will generate reply message in the commit phase. On the client side, if the client received 2/3 +1 reply messages from replicas, it will confirm the message. If less than 2/3+1, means something wrong in the network, data is not safe. This is how PBFT works. What will happen if the primary replica is down is that they will do view change and do 3PC consensus. let's go back to this PBFT slide, in the first phase, if the primary replica is down, rest replicas will re-select a primary replica. once a new primary replica is found, it will increase the TCP sequence number and start the PBFT process again. since all replicas will always accept the message with the highest TCP sequence number. + - On Tron, it will be a little bit different. We just have 3 stages. and SR plays both the client role and the replica role， once the block is produced, SR will broadcast it to network. we don't need the request and reply phase, we just need 3 phases to reach consensus. let's talk about how it works, in the first step, one SR start producing block and after that broadcast the block. in step 2, the SR(we also call it verify because they are used for different functions) start to verify the block and sign and multicast the pre-prepare message to the network. In step 3, it will verify the signature and multicast the commit message. after that, SR will check whether he received 2/3+1 commit messages, if yes it will make this block a solidate block. so it is like, for block S3, SR received more than 2/3+1 PBFT commit messages. so S3 will be set to solidate status, and all blocks ahead of S3 can be set to solidate status because blocks have a dependency on hash value, the hash value of S3 depends on hash values of S2, in this case, once S3 is confirmed all the way to S1 will be confirmed too. Any questions? + - How we handle fork, 2 rules, the first rule is the first received, whoever received 2/3+1 messages and confirmed the block that chain will be the main chain. Rule 2 is always choosing the longer chain as the main chain if we cannot get enough PBFT message to confirm the block. It is pretty much the same as DPOS. + - Let's see this example, we have 4 blocks in the red chain and only 3 in the green chain, however, the second green block was confirmed via PBFT messages, so the green chain is chosen to be the main chain although it is short. + - Let's see another example, as long as we do not receive 2/3+1 PBFT messages of any block of the two chains, the longer chain will be select as the main chain. if we received 2/3+1 PBFT message and confirmed that block, the chain with this block will be the main chain. any question? + +- Benson + - As you said, the first rule always got a higher priority than the second rule. on the second rule page, if we cannot get enough PBFT message, we will choose the longest chain as the main chain, if we finally got enough PBFT message for one block in the short chain, the main chain will jump to the short chain, right? + +- Xing + - probably, at the time 1, we choose the red chain as the main chain, and in the next 3 seconds, the green chain received PBFT message and then we switch to the green chain as main chain. so it likes, you start with a longer chain, and later switch to the short chain because the short chain is confirmed via PBFT message. This is how it works. + + - Performance is also a very interesting part. Old Tron consensus taking 19 time slots to confirm a block, which is like 1 minute, but for PBFT, we only take one time slot to confirm a block in theory, kind like 19 times performance improvement. You can find more info in TIP64 if you are interested. We just give a little bit proof, take a look at case 1, block producing order is A, B, C, D... all the way to N, however, the block receiving order can be different based on the network status. in Case 1 receiving order is ACEBHFGUDN. at the time of block F, if received 2/3+1 PBFT messages, then F will be confirmed, also BCDE will be confirmed, total 5 blocks were confirmed. if you do math, it is still O(1) average because from B to F is 15 seconds, and confirmed 5 blocks, the average time is still 3 seconds. for case 3, block receiving order is the same as producing order. The worst case is receiving order is reverted producing order, like case 2, receiving order is ATSRQP....BA, although it very happens, we still get O(1) confirm time on average. even we have 20 or 100 blocks not confirmed, if the next block is confirmed via PBFT message, we can confirm more than 100 blocks. + - In theory, we can always have O(1) to confirm the block on average, if you are interested in the proof part, check more info at TIP64 as it got math part there. + +- Dark + - what is the average confirm time for one block, 3 seconds? +-Xing + - Yes, O(1) slot time. + +- Benson + - I would say this is a huge improvement, can you also introduce some possibilities based on this improvement? + +- Xing + - This is our plan, SPV, we have PBFT message, inside PBFT message we have SR signature and NextSRList, I am pretty sure we had a meeting on SPV, check more info on our Github if you are not on the meeting. since we have SR signatures, so we can verify simple payment based on the block header. just compare the Merkle root then we can verify the transactions. It is like, first you got a transaction, then got the block, and then calculate the Merkel root, then get the hash value of Merkel root. + - The second plan is Cross chain, this is an ongoing project inside Tron. Nowadays we have so many cryptocurrencies, if they can do cross chain stuff, then I can use TRX by ETH/BTC, they can do mutual verification. + - Last I would like to say is performance optimization. The block header signature is too heavy, we want to make it light, we will improve the signature part. Also, we will improve the network transfer to make transfer faster. + + +- Benson + - Is there anyone who has any other things to talk about before we cut off? if no we can end the meeting now, The next meeting timeline and agenda will be updated on our GitHub after confirmed, we will also keep you updated in the telegram channel. Thank everyone for coming, thanks, bye. + +## Attendees +- CryptoGuyinZA +- Michael +- Tron +- Benson +- CryptoChain +- Xing +- Boram - NEOPLY +- Dark +- liang xiansheng +- cathy +- Sakary +- Mono +- Ray Wu +- Vinod +- Jason +- Philip Haslam +- Zimbocash Zash +- Ana diff --git a/TRON Core Devs Meetings/Meeting 09.md b/TRON Core Devs Meetings/Meeting 09.md new file mode 100644 index 0000000..e0175ea --- /dev/null +++ b/TRON Core Devs Meetings/Meeting 09.md @@ -0,0 +1,177 @@ +# TRON Core Devs Meeting 09 Notes + +### Meeting Date/Time: Thursday, Sep 24, 2020 09:00 AM UTC + +### Meeting Duration: 1 hour + +### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/14) + +### [Audio/Video of the meeting](https://youtu.be/jq_tvSXnXss) + +# Agenda + +- Latest update of java-tron +- Shielded transaction protocol +- Shielded TRC-20 contract ([TIP-135](https://github.com/tronprotocol/tips/blob/master/tip-135.md)) +- Zero-knowledge proof instructions in TVM ([TIP-137](https://github.com/tronprotocol/tips/blob/master/tip-137.md), [TIP-138](https://github.com/tronprotocol/tips/blob/master/tip-138.md)) +- Future plans of "TRONZ Shielded TRC-20 Contract" + +## Latest update of java-tron + +- Sakary + - The key update recently is version 4.1. This is a hard fork version. Proposal 40 will be put forward to use TPOS as the new block consensus method. + - The lite full node we've mentioned before will be available this time. At the time a lite full node starts, it only retains about the recent 50,000 blocks, which saves dozens of times of disk space. + - Also, we'll provide a dockerized solution for full nodes, I believe this can reduce much deployment time. + +## Zero proof knowledge + +* Matthew + + * Let’s start by what is Zero-knowledge proof. It is a method by which one party can prove to another party that something is true yet without revealing any information about the fact that this specific statement is true. So let’s say you want to prove that you have 1 million dollars and the verifier will ask you well show me your one million dollars pleases. but instead of showing to the verifier your 1 million dollars, you have some other method to prove it. let’s say you could prove that by showing off your credit card from the bank or your luxury car yards private jack or your big house. + + * All of the zero knowledge proof has the following 3 properties. the first one is that If the statement is true, the honest verifier will be convinced of this fact by an honest prover. the second, If the statement is false, no cheating prover can convince the honest verifier that it is true, except with some small probability (soundness error δ). and final one, If the statement is true, no verifier learns anything other than the fact that the statement is true. That is the fundamental of the zero-knowledge proof. + + * Over the decades, numerous research was proposed about zero-knowledge proof. now there are 3 major zero-knowledge proof methods that are widely used in the blockchain industry. BulletProof, zk-STARKs and zk-SNARKs. Among 3 of them, we took the zk-SNARKs as our implementation approach. + + * Look to different properties of the 3 methods. zk-SNARKs has the smallest proof size compare to the others. Again in terms of verification time case, zk-SNARKs performs the best as well. while there are some compromises on the prove time, which is 40% more than zk-STARKs. and it is the only method that requires a trust setup. and we believe using zk-SNARKs could provide the user the best experience to TRON, so therefore, we think it is the best method to take. + + * Underneath the zk-SNARKs scheme, it involves a lot of complex cryptographic theory, which I am not going to go through all the process one by one here today, but the basic idea is like this. you want to transform a statement something that you want to prove, for example like i know the keys that allow me to spend a shielded transaction, turns it to an equivalent form of a quadratic arithmetic program, and the prover has to show that he/she knows the solution of this program, therefore, he/she will have the right to spend the shielded token, well zero-knowledge proof can play a key role for privacy protection in blockchain, and it can be used to prove that the conditions of the valid transaction have been met without revealing anything. + + +## Shielded transaction protocol + +* Matthew + + * We have to apply the shielded account system which is quite different from our ordinary account. we have a bunch of keys to create to perform operations. all the keys are generated based on one spending key. Well, it seems very complicated and troublesome to you through all the apps with these keys, we prepared one single API for you to create all the keys with simple calling to this API in your node. you will have all the keys I have mentioned, and also a shielded payment address as well. + * The shielded transaction protocol is based on the UTXO model. that is the same protocol used in the bitcoin. each shielded output is a note in which the note consists of a payment address, the transaction amount, and a random number. so when the user spends a note, you need first generate a spend description with the listed inputs. one thing I want to highlight is that we only put the commitment of the value on to the chain, not the value itself. therefore it provides better privacy for users. The same goes for shielded output as well. it needs to generate a received description. and you will see some similarities here. the purpose of put the note commitment instead of the note itself onchain, It is the same as that of the value commitment. + * With both the spend description and received description. they form the input and output of a transaction respectively, with each transaction links to one and other, it forms The whole UTXO model. + + + +## TIP-135 + +* Matthew + * The shielded TRC20 Contract was introduced in TIP 135. the purpose of it is to implement the functions to hide the source address, the destination address, and also the token amount for the TRC20 transactions. well with all this information hidden then you can call it shielded, right. We do that by implementing 3 core functions, which is the mint, transfer, and burn functions. + * First the mint function is to transform the public TRC-20 token into shielded token
1 transparent input and 1 shielded output, for transfer, it is used for shielded token transactions, which can hide the source address, the destination address, and the transaction amount. 
<=2 shielded input and <=2 shielded output. finally, the burn function is to transform the shielded token back to the public TRC-20 token
1 shielded input, 1 transparent output, and 0 / 1 shielded output. + * Well it will be easier for you to understand the whole picture when you look at the flow diagram. let’s say we have Alice and bob here, Alice has 100 JST tokens, she wants to pass it these token to bo secretly, no one would like people to know what they are doing. Alice will do `mint` operation, then the JST token will become a shielded token in the shielded TRC20 contract. Then Alice may also perform some transfer process in the contract meanwhile. Now Bob can burn the shielded token back to the pub form. Nobody would know there are transactions between Alice and Bob. +* Benson + * I got one question, is the shielded contract applicable for all TRC20 standard tokens? +* Matthew + * Yes, it is applicable for all TRC20 tokens. You can bind the TRC20 contract to your shielded contract when you deploy the contract. + +## TIP-137 and TIP-138 + +* Matthew + * Now all these 3 core functions were implemented, they are based on the zero-knowledge proof and there is some complex verification process we heave to implement in TVM. Therefore we also introduced 4 functions in order to speed up the process in TIP-137 and TIP-138. As you can see there are 3 verify proof instructions to verify the proof of mint, transfer, and burn function. With one additional Pedersen hash instruction. + * So like a TRC20 contract, it has a set of protocols which you have to follow, by implementing these 3 verified instructions, they also created a standard of how a shielded contract should be, therefore they could all cover all the transactions which would happen inside the shielded contract. as you need to have all these functions verified. In order to get your shielded contract complete, all these verify proof functions only take 10 ms, so it won’t cost you a lot of time. one addition is that we also implement the Pederson hash instruction. it will help to compute the node value inside the Merkle tree, and also return a node value which is the parent node value. it may support a Merkle tree up to a depth of 64, but in shielded contract, we choose to use a 32 level Merkle tree. again it is super efficient, it only costs less than 1 ms. well for more details about the verify proof instructions you may proceed to TIP-137 and TIP-138. + * Well as that in the beginning, our zk-SNARKs method need a trusted setup, therefore we organized the multi-party computation torch project back in June. it is launched by Justin sun the founder of TRON. as you can see Justin himself did participate in this torch project, there are by far 196 participants, including developers from the TRON community, blockchain enthusiasts, those from traditional industry, active daily users, and KOLs. and it is the most participated MPC by numbers in the blockchain. + * Now let's compare our solution with some other famous zero-knowledge proof projects within the blockchain industry. The first one is Monero, Monero has a medium-range in privacy and complexity. It uses a RingCT protocol, it is linear with its ring size, it uses the bulletproof method. as we mentioned in the beginning, the bulletproof method has a very poor performance. The second one is Zcash, many of us already know its privacy is perfect but it is also complex, it uses the zk-SNARKs but it doesn't support shielded contracts and therefore it has a very limited extension in terms of privacy. Grin, medium privacy, and low complexity, it uses a mimblewimble protocol and with a Pedersen commitment, it can hide the transaction amount. It requires the sender and receiver to have some interaction beforehand. it is not very convenient, again it uses a bulletproof method. and the performance is very poor as well. Tornado is a pretty famous mixed solution on the Ethereum blockchain, it is quite complex, it supports the shielded contract, if you try to use their interface you will know that you could only deposit and withdraw a dedicated amount of token. If you want to transfer 2 tokens you have to do transfer 2 times as it can only support sending Ethereum one by one or 0.1, or 0.01. it is a dedicated amount. it is not that convenient. also the mixed solution, the privacy is proportional to the number of users. if only 1 or 2 users use it, it will be very easy for people outside to guess and find out who is doing transfer to who. Aztec, it supports shielded amount, but it will generate one -time public address for the sender and receiver. so the privacy is not that high. and compared to our shielded Contract, it has the privacy level as high as Zcash, it has a great performance, low transaction fee, and it is extendable with smart contract. It is more convenient than most of the other projects out there. + * We are devoted to the research of frontier cryptographic techniques and 
want to make a contribution to the privacy protection in the blockchain. So whenever there are new things coming out in the blockchain, we will try our best to study it, dig it and bring it to the blockchain as fast as we can. we have a lot of plans as well, so we would want to launch ZK-rollup which is to improve the scalability of blockchain, also we are trying to build a Zero-knowledge virtual machine for the general purpose of privacy protection scheme in the Dapps. We would like to implement more multi-party secure computation, more is coming. +* Ethan + * You mentioned the shielded transaction is very time consuming, maybe it will impact the normal transactions, I want to know how many shielded transactions can be packaged to one block, is there any limitation? +* Matthew + * Currently there are no limitations for the number of shielded transactions to be packed, it would be decided by the block capacity itself. if you are asking about will the shielded transaction takes a long time and it would affect the TPS, well I would say that is is as fast as the ordinary transaction, so there is no influence on the TPS at all. Also, it like the multi-sign feature as well, we provide the feature, but they are optional, for most scenarios people would be okay with the ordinary transaction, of course there are some drawbacks, now all people would use shielded transaction, it will not influence the whole blockchain size a lot. you may decide whether to use it or not. + +## How to do mint and transfer via the wallet-cli + +* Leo + + * I'm Leo from Tronz team. Next, I will show how to use Wallet-cli to perform the shielded transfer in Nile testnet. First, we edit the config file, here you can see this is the fullnode of our Nile testnet. last, this is the item we used in the shielded transaction, it is the block number in which the earliest shielded contract was created. in nile, we set it to 8556000, this is the block number when we deploy the shielded contract. + + * Let us start the wallet-cli, first login in with a public account, we input the password, and this account should have enough trx to trigger contract. Then I will show how to use shielded wallet. + + * Let us first use `SetShieldedTRC20ContractAddress` command to set contract address. this command requires 2 parameters, one is the TRC20 contract address, the second is the shielded contract address. + + `SetShieldedTRC20ContractAddress TAT7gKVukDxxo7yrcGuGCQbrDxJDiPQknu TN3xLkuXFSdT9Kiu61WSiHeP6WYQyLyxFZ` + + * This command will trigger the shielded contract and get the scaling factor, now you can see the `Scaling Factor` is 1, and when you perform shielded transfer, the amount should be an integer multiple of 1. This `Scaling Factor` is set when the shielded contract was deployed. + + * Now let me load the shielded wallet, it fails because the shielded wallet does not exist, we can use `ImportShieldedTRC20Wallet` command to import one, or we can use `GenerateShieldedTRC20Address` to create one. here we use `GenerateShieldedTRC20Address`. this command needs at most 1 parameter, the number of addresses you want to generate. if you want to generate 1 address, just run this command with no parameters. for example, this command `GenerateShieldedTRC20Address 2` will generate 2 shielded addresses. + + * you can use `LoadShieldedTRC20Wallet` to show the shielded address in local shielded wallet. there are 3 shielded addresses. let's begin to transfer shielded notes. the command of shielded transfer is `SendShieldedTRC20Coin`. All of the shielded transfers, MINT, TRANSFER, and BURN are done through this command. + + * `SendShieldedTRC20Coin` needs at least 6 parameters according to the type of shielded transfer. And next, we will explain the meaning of each parameter by performing a `MINT` transaction. I will transfer 1M tokens from a public account to a shielded one. + + `SendShieldedTRC20Coin 1000000 0 null 0 1 ztron1xx7fwdafkm4nwwup3p0syvrs3rnzchgqk94k59macvlcyll07vql5h3w5psh2a599vp5gn3lgzr 1000000 mint1M` + + * The first parameter is the amount to mint. next is the number of shielded inputs. because this is a MINT transaction, there are no shielded inputs, so this fielded is set to 0. Also the next fields `input1 input2` are ignored. Next is the public address of output, it is null. and the public amount is 0. Then we fill the fielded of shielded outputs. The number of shielded output is 1, and the shielded address is `ztron1xx7fwdafkm4nwwup3p0syvrs3rnzchgqk94k59macvlcyll07vql5h3w5psh2a599vp5gn3lgzr`, amount is 1000000. At last, it is the memo field. You can set some message to the receiver. + + * This needs to input password twice because this command included 2 transactions. One is to trigger `approve` function in TRC20 contract, and the other one is to trigger 'mint' function in the shielded contract. + + * Let's use `GetTransactionInfoById` command to check the result of this transaction. Look, the contract result is `SUCCESS`. The receiver can use `ListShieldedTRC20Note` command to check this shielded note. + + `0 ztron1xx7fwdafkm4nwwup3p0syvrs3rnzchgqk94k59macvlcyll07vql5h3w5psh2a599vp5gn3lgzr 1000000 26ebe11c39cb68e2fad5dd6284a1a3b4dccd53b51ccfe4b805529b3e6398f475 0 UnSpend mint1M` + + * The first one is the index of local scanned note. the second is the address, then the amount, transaction ID, and the next one is the index of shielded output in the transaction. next is the status of this note. the last one is the memo. + + * This is MINT transaction. Next, I will show the TRANSFER transaction. Before we show TRANSFER, let's login in with another public account. It's better to use different accounts to trigger BURN, TRANSFER, and MINT. + + * We will spend the first note, and use the same command `SendShieldedTRC20Coin`. + + `SendShieldedTRC20Coin 0 1 0 null 0 1 ztron1llqp5jfexk3zaalu96t8gh3zrm49q90uaa4f72xku7djrh82tcelhf43jmj0zn870f6c2cw7dnf 1000000 transfer1M` + + * We don't need any public input, the first parameter is 0. The number of shielded input is 1, the next input the index of shielded note. We have no public output, so publicToAddress is filled with null and toPublicAmount is 0. Next, the number of shielded output is 1, and fill in the shielded address of the receiver. last is the memo. + + * Let's check the result use command `GetTransactionInfoById`, look, it succeeds. Let's use `ListShieldedTRC20Note` to check out the received note. + + * And you can also use `ListShieldedTRC20Note` command to check all the notes, including spent and unspent notes. just give the command a parameter. + + `ListShieldedTRC20Note 1` + + * The second one is the note we just spend. `ztron1xx7fwdafkm4nwwup3p0syvrs3rnzchgqk94k59macvlcyll07vql5h3w5psh2a599vp5gn3lgzr 1000000 26ebe11c39cb68e2fad5dd6284a1a3b4dccd53b51ccfe4b805529b3e6398f475 0 18 Spent mint1M` + + * This fielded is the index of this note in the leaf level of Merkle tree. + +* Crypto Chain + + * Where to set the TRC20 token id, like the token being bind to the contract? + +* Leo + + * In this nile test net, the TRC20 contract is deployed by ourselves for testing. if you want to use TRC20 in the main net, you need to have enough TRX and deploy a shielded TRC20 contract there. + +* Crypto Chain + + * So basically every TRC20 token must have a shielded contract operate the shielded transactions. where did you specify the TRC20 shielded contract in the command lines？ + +* Leo + + * We use `SetShieldedTRC20ContractAddress` to connect the TRC20 contract and the shielded contract. + +* Benson + + * Do you have any other questions before closing the meeting？If no, we can close the meeting now, The timeline and agenda of the meeting 10 will be updated on our Github after confirmed, we will also keep you updated in the telegram channel. Thank everyone for coming, thanks, bye. + + + + + +## Attendees + +- Benson + +- Leo + +- Federico + +- Sakary + +- Matthew + +- Joanna + +- Mono + +- Michael + +- CryptoChain + +- Ethan + +- SunSeekerX + +- Frozen + +- Tron + +- CryptoGuyinZA