[{"data":1,"prerenderedAt":289},["ShallowReactive",2],{"docs-\u002Fdocs\u002Fcore-tech\u002Fconfidential-assets-(historical)":3,"docs-surround-\u002Fdocs\u002Fcore-tech\u002Fconfidential-assets-(historical)":279},{"id":4,"title":5,"body":6,"description":270,"extension":271,"image":272,"meta":273,"navTitle":272,"navigation":274,"path":275,"seo":276,"stem":277,"__hash__":278},"docs\u002Fdocs\u002Fcore-tech\u002FConfidential-assets-(historical).md","Confidential Assets (historical)",{"type":7,"value":8,"toc":258},"minimark",[9,21,29,35,38,50,55,72,78,98,102,111,126,129,134,141,147,151,160,163,166,170,177,188,198,203,206,213,216,219,222],[10,11,12,13,20],"p",{},"Consult the ",[14,15,19],"a",{"href":16,"rel":17},"https:\u002F\u002Fgithub.com\u002FBeamMW\u002Fbeam\u002Fwiki\u002FMW-CLA",[18],"nofollow","MW CLA"," section for Confidential Assets implementation details",[10,22,12,23,28],{},[14,24,27],{"href":25,"rel":26},"https:\u002F\u002Fgithub.com\u002FBeamMW\u002Fbeam\u002Fwiki\u002FConfidential-assets-(BETA)",[18],"Confidential assets (BETA)\n"," section for the Confidential Assets tutorial",[10,30,31],{},[32,33,34],"strong",{},"THE TEXT BELOW IS KEPT FOR HISTORICAL REASONS",[36,37],"hr",{},[10,39,40,41,45,46,49],{},"MW can be extended to allows encoding multiple types of assets to be traded on the same blockchain. And it will only need a slight modifications to actually allow this.\nThere are two types of assets that can be implemented: ",[42,43,44],"em",{},"predefined"," and ",[42,47,48],{},"custom",". Each type has its advantages and limitations.",[51,52,54],"h2",{"id":53},"basic-idea","Basic idea",[10,56,57,58,45,62,65,66,68,69,71],{},"The UTXO is an EC point, which is a linear combination of two nums (nothing-up-my-sleeve) generators: ",[59,60,61],"code",{},"G",[59,63,64],{},"H",", whereas ",[59,67,61],{}," is multiplied by the secret key (blinding factor), and the ",[59,70,64],{}," - by the value.",[10,73,74,75,77],{},"To allow multiple types of assets it's sufficient to use different generators (one per asset type) instead of the single ",[59,76,64],{},". There may be different schemes to represent such UTXOs, but in any of them the following should be taken into consideration:",[79,80,81,92,95],"ul",{},[82,83,84,85,91],"li",{},"Those ",[86,87,88],"u",{},[32,89,90],{},"must"," be nums-generators, and the verifier should be able to verify this.",[82,93,94],{},"The verifier should be able to verify the rangeproof. Means - the bulletproof should be adjusted accordingly.",[82,96,97],{},"There should be a brief scheme for the emission of the assets.",[51,99,101],{"id":100},"predefined-asset-types","Predefined asset types",[10,103,104,105,110],{},"This idea belongs to Andrew Poelstra. Described ",[14,106,109],{"href":107,"rel":108},"https:\u002F\u002Fblockstream.com\u002F2017\u002F04\u002F03\u002Fblockstream-releases-elements-confidential-assets.html",[18],"here",".",[10,112,113,114,117,118,121,122,125],{},"Each UTXO should carry a ",[42,115,116],{},"tag",", which is an EC point, which defines the asset type. The great advantage of this scheme is that all the tags are ",[32,119,120],{},"blinded",". Means - anyone can verify that this tag corresponds to one of the defined asset types, but not to which of them exactly. This is achieved by using Andrew Poelstra's ",[86,123,124],{},"Asset Surjection Proof",", which has a modest size compared to the bulletproof for a reasonably-small set of asset types.",[10,127,128],{},"The set of the asset types, as well as their emission schedule, must be defined for the blockchain. Any change to this will require a fork.",[130,131,133],"h3",{"id":132},"another-variant","Another variant",[10,135,136,137,140],{},"Another possible way to implement this is to encode all the asset types within a single UTXO. That is, each UTXO is presumably a linear combination of all the generators at once. In this design ",[42,138,139],{},"tags"," are not needed.",[10,142,143,144,146],{},"The drawback here is the increased complexity and size of the bulletproofs, which seem to be dramatic. So that the idea with ",[42,145,139],{},", whereas an UTXO encodes only a single asset type - seems to be better.",[51,148,150],{"id":149},"custom-asset-types","Custom asset types",[10,152,153,154,156,157,159],{},"In addition there is a possibility to allow ",[42,155,48],{}," assets, which any user can emit and trade. As in the previous scheme, such UTXOs should carry a ",[42,158,116],{},", which corresponds to the asset type. But this time those tags can't be blinded perfectly. All the user can do is present a set of tags, and prove that the used tag is one of them.",[10,161,162],{},"So that custom tags should either be visible, or partially obfuscated. The encoded amount, naturally, is fully concealed.",[10,164,165],{},"Now, since there are no predefined generators used for custom asset types, there should be a way for the verified to make sure each such a generator is actually a nums-generator. This is addressed by the following scheme.",[130,167,169],{"id":168},"asset-control","Asset control",[10,171,172,173,176],{},"To create a custom asset type the user generates a public\u002Fprivate key pair. The public key serves as an ",[42,174,175],{},"Asset ID",", and the generator used for this asset type is derived from the ID via hashing, so that it may be considered as a sound nums-generator.",[10,178,179,180,183,184,187],{},"The user controls the emission and collection of the asset. The user can ",[42,181,182],{},"convert"," some amount of the master asset type (i.e. BEAM) into his\u002Fher type by a special instruction, which is signed by the corresponding ",[32,185,186],{},"private"," key. For convenience it can be embedded into the transaction kernel.",[10,189,190,193,194,197],{},[32,191,192],{},"Note:"," The conversion is only needed to prevent bloat. The user effectively ",[42,195,196],{},"buys"," his\u002Fher coins, but they are refundable. Only the user is be able to trade the unspent assets back to collect the refund. If the bloat is not an issue - it's possible to allow the emission for free.",[199,200,202],"h1",{"id":201},"final-design","Final design",[10,204,205],{},"The BEAM should support both the predefined and custom assets.",[10,207,208,209,212],{},"There should be several predefined asset types, which are automatically emitted by every new block. Their difference is the ",[86,210,211],{},"emission schedule",". There should be one with constant emission, one with capped emission. Possibly another one with declining but non-converging (e.i. not capped) emission.",[10,214,215],{},"This is equivalent to having several coin types suitable for instant payment, store of value, and etc.",[10,217,218],{},"Custom asset tags are not emitted automatically, they're explicitly traded for one of the predefined types.",[10,220,221],{},"The modifications needed to support all this is considerable, but straightforward. The following should be modified:",[79,223,224,227,230,244],{},[82,225,226],{},"Tags should be added to UTXOs",[82,228,229],{},"For predefined types: Assert Surjection proofs should be added to UTXOs",[82,231,232,233],{},"For custom types:\n",[79,234,235,238],{},[82,236,237],{},"Assert Surjection proofs may optionally be used, in addition to a list of the possible asset types.",[82,239,240,241,243],{},"Another possibility - they should not be blinded, and contain the ",[42,242,175],{}," explicitly.",[82,245,246,247],{},"Transaction\u002FBlock verification:\n",[79,248,249,252,255],{},[82,250,251],{},"Bulletproof code should be modified to support custom generators (probably slight performance degradation)",[82,253,254],{},"Custom type conversion instruction should be supported, but this is straightforward (only alters the summation to zero criteria)",[82,256,257],{},"Block emission should be handled w.r.t. predefined types and their emission schedule.",{"title":259,"searchDepth":260,"depth":260,"links":261},"",2,[262,263,267],{"id":53,"depth":260,"text":54},{"id":100,"depth":260,"text":101,"children":264},[265],{"id":132,"depth":266,"text":133},3,{"id":149,"depth":260,"text":150,"children":268},[269],{"id":168,"depth":266,"text":169},"Consult the MW CLA section for Confidential Assets implementation details","md",null,{},true,"\u002Fdocs\u002Fcore-tech\u002Fconfidential-assets-(historical)",{"description":270},"docs\u002Fcore-tech\u002FConfidential-assets-(historical)","InvZ6zOCyTRdUpKRBOjnvrtdytia3_YIYZIGjhBHb9g",[280,285],{"title":281,"path":282,"stem":283,"description":284,"children":-1},"Confidential Assets","\u002Fdocs\u002Fcore-tech\u002Fconfidential-assets","docs\u002Fcore-tech\u002FConfidential-assets","This documents describes CLI Confidential Assets workflow.",{"title":286,"path":287,"stem":288,"description":259,"children":-1},"Beam Contribution Guidelines","\u002Fdocs\u002Fcore-tech\u002Fcontribution-guidelines","docs\u002Fcore-tech\u002FContribution-Guidelines",1783006064014]