Shulou(Shulou.com)06/01 Report--

This article shows you how to implement the anonymous version of Ethernet Cat in the way of DApp. The content is concise and easy to understand, and it will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Privacy protection of blockchain development platform now

We basically know that ethernet is a blockchain application development platform. Based on the network and intelligent contract language built by ethernet, we can implement a variety of distributed applications (DApp) that are close to the real world. Although this kind of decentralized distributed application based on intelligent contract is a kind of innovation, it unwittingly arouses the market's concern about information security. At present, all the transactions of an account and the funds of the account can be easily traced through the eTaifang block browser, which basically does not have any threshold. As long as you can access the Internet, you can analyze the capital flow of an account, as well as the holding of money, which has no privacy for individuals.

SERO: the world's first anonymous public chain that supports smart contracts

At present, there are popular anonymous block chain technologies such as Monero, DASH and Zcash. Although all of them can protect privacy anonymously, they do not support smart contracts and cannot be used to develop DApp. The common chain of the Super Zero Protocol (SERO) [white paper] is an anonymous public chain that supports Turing's complete intelligent contract, uses zero knowledge proof for privacy protection, and has released a beta version. SERO seems to be a perfect solution for privacy protection, and anonymous DAPP can be developed on it.

An overview of the ethernet cat program on ethernet square

Ethernet cat should be the most mature and successful Dapp in ethernet by far. It caused a traffic jam in ethernet place in a very short time. Ethercat is developed according to ERC721, the intelligent contract code is about 2, 000 lines, the source code is open source on github, and can also be found in the ethernet block browser.

The ethernet program includes seven main programs:

1. KittyAccessControl, a contract that manages various addresses and constraints that can only be performed by a specific role. These characters are called CEO, CFO and COO.

2. KittyBase, a contract that defines where the most basic code is shared throughout the core function. This includes our main data stores, constants and data types, as well as internal functions for managing these data.

3. KittyOwnership, which provides the method needed for basic non-interchangeable token transactions that follow the draft ERC-721 specification.

4. KittyBreeding, this document contains the methods necessary to breed cats together, including tracking breeding providers and relying on external genetic combination contracts.

5. KittyAuctions, here, there are open ways to auction cats or bid cats or breed cats. The actual auction function is handled in two sibling contracts (one for buying and selling and the other for reproduction), while auctions are created and bid mainly through core contracts.

6. KittyMinting, which includes features to create a new gen0 cat

7. KittyCore, the main CryptoKitties contract, compiles and runs on the ethernet block chain. This contract ties everything together.

Anonymous version of Ethernet Cat implementation

According to SERO's DApp programming specification, an anonymous version of ethercat DApp can be implemented. At present, the function of SERO to support "issuing anonymous bills" has been released, which corresponds to the Ethernet Fong ERC721 protocol and is the basis for the implementation of Ethernet cats.

Ticket (Ticket) related interface definition

The SERO team deployed a Remix-ide site with an example called SeroInterface.sol, which mainly provides interfaces for publishing anonymous token and ticket, which should be system interfaces that must be inherited as long as they want to be anonymous. According to the example provided by the SERO team, the system-defined log Topic must be included in the interface for generating and transferring Ticket

/ * the follow topics is system topics,can not be changed at will * / bytes32 private topic_sero_send = 0x868bd6629e7c2e3d2cf7b9968fad79b448e7a2bfb3ee20ed1acbc695c3c8b23; bytes32 private topic_sero_allotTicket = 0xa6a366f1a72e1aef5d8d52ee240a476f619d15be7bc62d3df374960b83459f; bytes32 private topic_sero_category = 0xf1964f6690a0536daa42e5c57509129d2479edcc96f721adb95844d276; bytes32 private topic_sero_ticket = 0x9ab0d7c07029f006485cf3468ce7811aa8743b5a108599f6bec9367c50ac6aad

Judging from the topic defined above, every type of Ticket must have a category attribute, similar to syboml in ERC721.

SeroInterface mainly provides the following APIs that are needed to write an anonymous version of Ethernet:

1. Generate ticketId and deposit ticketId directly into personal account.

/ * * @ dev generate a tickeId and allot to the receiver address * @ param _ receiver receiving address of tickeId * @ param _ value the seq of tickeId,can be zero. If zero the system, the system randomly generates * @ param _ category the category of the ticket * / function sero_allotTicket (address _ receiver, bytes32 _ value, string memory _ category) internal returns (bytes32 ticket) {bytes memory temp = new bytes (96) Assembly {let start: = temp mstore (start, _ value) mstore (add (start, 0x20), _ receiver) mstore (add (start, 0x40), _ category) log1 (start, 0x60, sload (topic_sero_allotTicket_slot) ticket: = mload (add (start, 0x40))} return;}

two。 Get the category in the transaction parameters

/ * @ dev the get category from the tx params * / function sero_msg_category () internal returns (string) {bytes memory tmp = new bytes (32); bytes32 b32; assembly {log1 (tmp, 0x20, sload (topic_sero_category_slot)) B32: = mload (tmp)} return bytes32ToString (b32);}

3. Get the ticketId in the transaction parameters

/ * * @ dev the get ticketId from the tx params * / function sero_msg_ticket () internal returns (bytes32 value) {bytes memory tmp = new bytes (32); assembly {log1 (tmp, 0x20, sload (topic_sero_ticket_slot)) value: = mload (tmp)} return;}

4. Deposit the ticketId in the transaction to the recipient's personal account

/ * @ dev transfer the tickeId to the receiver * @ param _ receiver the address of receiver * @ param _ category the category of ticket * @ param _ ticket the tickeId * / function sero_send_ticket (address _ receiver, string memory _ category, bytes32 _ ticket) internal returns (bool success) {return sero_send (_ receiver, "", 0meme _ category, ") } / * * @ dev transfer the token or ticket to the receiver * @ param _ receiver the address of receiver * @ param _ currency the currency of token * @ param _ amount the amount of token * @ param _ category the category of the ticket * @ param _ ticket the Id of the ticket * / function sero_send (address _ receiver, string memory _ currency, uint256 _ amount, string memory _ category, bytes32 _ ticket) internal returns (bool success) {bytes memory temp = new bytes Assembly {mstore (temp, _ receiver) mstore (add (temp, 0x20), _ currency) mstore (add (temp, 0x40), _ amount) mstore (add (temp, 0x60), _ category) mstore (add (temp, 0x80), _ ticket) log1 (temp, 0xa0, sload (topic_sero_send_slot) success: = mload (add (temp, 0x80))} return;}

The ticketId generated by the intelligent contract inheriting SeroInterface will be directly saved to the personal account, and the intelligent contract does not need to manage the assets of the personal account. Therefore, when transferring the ticket, the ticketId and category must be passed through the transaction parameters, not through the parameters of the intelligent contract method, and the transferred ticketId will eventually be directly stored in the recipient's personal account. After figuring out the interfaces provided by the above SERO, the changes to the ethercat are simple. To some extent, it will be easier to write the ethercat on the SERO, and there should be less code.

KittyBase

Because all the data types of ticekId on SERO become bytes32, you need to change all the data types of all ticketId in KittyBase from uint32 to bytes32 at once.

Struct Kitty {bytes32 kittyId; uint256 genes; uint64 birthTime; uint64 cooldownEndBlock; bytes32 matronId; bytes32 sireId; bytes32 siringWithId; uint16 cooldownIndex; uint16 generation; address owner;}

After the data type of kittyId is changed, some corresponding data interfaces also need to be adjusted, and the kittys in KittyBase needs to be changed from array type to map.

Mapping (bytes32 = > Kitty) kittys

From the source code of SERO, the first step in anonymous transactions is the anonymous account address, and the account address involved in all transactions is replaced by an one-time address, so the sireAllowedToAddress in the previous KittyBase is changed to sireAllowedToTokenId. The mapping from tickeId to account is changed to that from tickeId to ticketId.

Mapping (bytes32 = > bytes32) public sireAllowedToTokenId

Delete the attributes kittyIndexToOwner and ownershipTokenCount, because all ticekId are eventually stored in personal accounts, so there is no need for smart contracts to save the relationship between ticketId and accounts.

When generating Kitty, call the sero_allotTicket method in SeroInterface.sol directly in the _ createKitty method to generate kittyId and save the kittyId to owner's personal account without calling the _ transfer method once.

KittyOwnership

Since the kittyId created by the smart contract is directly sent to the personal account, there is no need for such methods as ownerOf and tokensOfOwner in this file. As long as you can query it in your personal account and pass the kittyId to the smart contract through the transaction parameters, it will prove that your account has this kittyId. Therefore, in the end, there are only two methods for the smart contract: transfer and totalSupply.

Because this is a simple attempt, many places have been simplified. The method related to approve has been deleted, and if you need to add it, I think the idea is to change the mapping from kittyId to account to the mapping from kittyId to kittyId to weaken the address. As long as you can send the kittyId through the transaction, you can prove that you own the kittyId, and the reasoning in turn proves that the kittyId owner is the account address you need to grant credit to. In the final implementation, it is found that the approve method may not be needed in the anonymous version of the ethercat.

KittyBreeding

This file should not need to be changed, because the sireAllowedToAddress is changed to sireAllowedToTokenId, so you only need to modify the approveSiring method.

Function approveSiring (bytes32 _ matronId) external whenNotPaused {/ / get _ sireId A Kitty that you own from the tx param bytes32 _ sireId = sero_msg_ticket (); sireAllowedToKittyId [_ sireId] = _ matronId; / / Re-save _ sireId to your personal account after approval sero_send_ticket (msg.sender,symbol,_sireId);}

_ sireId is passed to the smart contract through the transaction parameters, so you need to call the sero_msg_ticket method of SeroInterface to get the ticekId in the transaction parameters. Because _ sireId is passed through the transaction parameter, the SERO chain will mark _ sireId from your personal account as used, and you will no longer own the _ sireId. However, the authorization is only implemented here, and the asset transfer is not required, so you need to deposit the _ sireId into the personal account again at the end of the method.

KittyAuction

Delete the _ kittyId parameter in the createSaleAuction and createSiringAuction methods, and all the parameters are obtained by calling SeroInterface's sero_msg_ticket method from the transaction parameter. This is slightly different from the implementation of Etay Square. The previous practice of Etai Fang is to grant credit to saleAuction and siringAuction, and then transfer _ kitttyId to your account for hosting through nonFungibleContract. Since the kittyId on the SERO chain is stored in the personal account, and the kittyId is passed through the transaction parameters when creating the auction, once the transaction is successful, it is impossible for kittyId to use this kittyId again, so there is no need to host this step. After the bid method is called, the kittyId is directly stored in the personal account of winner.

Delete the parameter of _ matronId in the bidOnSiringAuction method, the caller passes it through the transaction parameter, and then get it through the sero_msg_ticket method in the method body. The situation here is similar to that of approveSiring in KittyBreeding. A very important point passed by _ matronId through transaction parameters is that it is used for identity verification and does not reverse the transfer of assets, so at the end of the method, you need to deposit the _ matronId into your personal account again.

At this point, the core of the ethercat has been modified, and because the intelligent contract of GeneScienceInterface has not been published, the mixGenes method is replaced by generating random numbers. Those who are interested can go to the Internet to find the cracked version.

The core part of ethernet is based on ERC721 (non-homogeneous token protocol), followed by the core business logic. The implementation of the anonymous version of Ethernet Cat is mainly to adjust the implementation part of the ERC721 interface. According to the interface provided by the SERO team in SeroInterface.sol, the Ethernet Square ERC721 function can be fully realized, so the above adjustments are mainly aimed at the generation, storage, authentication and parameter transfer of kittyId.

Because the kittyId generated on SERO, whether it is created or traded, will eventually be directly stored in a personal account, there is no need for smart contracts to manage the attribution of kittyId. When calling the intelligent contract method, all the places that need to pass the kittyId that you own must be passed to the intelligent contract through the transaction parameters. It is important to note that the kittyId in the transaction parameters will be marked from the personal account as used on the SERO chain, and you will no longer own the kittyId. If the kittyId passed through the transaction parameters is only used as authentication and does not need to be transferred, keep in mind that in the smart contract method, the kittyId needs to be stored in the personal account again.

The first step for SERO to achieve anonymity is to write about the address. Whether it is the address in the transaction or the address passed into the intelligent contract, it will be converted into an one-time address. In the end, only people who own the address can query their assets and use these assets, which invisibly weakens the effectiveness of the address. There is a situation in ethernet cats where kittyId is granted to an address, which is obviously not possible in SERO, because the address passed into the smart contract may be different each time, even if it is the same address. Although it is impossible to grant credit directly to an address, SERO can also achieve similar functions, as long as we change our thinking. Because all the assets of SERO are saved in a personal account, for people with non-homogeneous tokens, an tickeId can prove the identity of an address under certain circumstances, so when giving credit to an address in Tai Cat, it can be replaced with a way to grant credit from one kittyId to another kiettyId. The kittyId of the recipient must be passed to the smart contract through transaction parameters. After figuring out some of the major changes mentioned above, it is easy to anonymize ethercat without changing its business logic. The amount of code will be less than the original, and the asset management logic will be reduced, so the main focus of implementation is on the business logic.

Through SERO, not only Ethernet anonymization can be achieved, but also SERO for intelligent contracts simplifies asset management logic while supporting anonymity, so that all DApp developers can focus on business logic development. In some cases, SERO lowers the threshold for issuing tokens through smart contracts, making it easier for traditional App developers to develop their own DApp.

The above is how to implement the anonymous version of Ethernet cat in the way of DApp. Have you learned the knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.