Package: x21e8
0x21e8 RDDL Interaction ServiceThe 0x21e8 service is usually installed and executed on RDDL compatible hardware wallets (HW-03). The service utilizes the hardware wallet and enables the HW-03 devices to interact with the RDDL network (Planetmint and liquid).Besides the pure wallet functionality it works as the core service to launch any RDDL specific use cases:storage of (un/encrypted) data (w3storage (IPFS))attestation of dataattestation of machinesissuing of tokenslookup of datalookup of tokenscombination of data & tokensThe current version runs with a software-based keystore. Production based versions will use keystores based on secure elements. Initialization and configuration of the keystores is currently enabled via API.The service exposes all features via a RESTFul API. The documentation of the API is exposed via <ip/hostname>/docs.WARNINGuse this code only for demonstrational purposes. Production code must not rely on this service.Prepare the EnvironmentPlease run the following scripts to install 0x21e8 service ()### For a RPI: some architectures need to get a zenroom and dependencies build from source (glibc compatibility)bashinstall.shThe script basically prepares your system to build the service and installs some requirements for this.Very often, poetry can be used directly without any indication to build some packages from source. Then, the following instruction will be sufficient:curl-sSLhttps://install.python-poetry.org|python3-# installs poetrypoetryinstall
poetryshellService ConfigurationThe service needs the following configurations:RDDL network planetmint services (RESTFul)RDDL network liquid services (RPC)RPC URLRPC portRPC userRPC passwordweb3storage token to store dataRDDL asset registration endpointRDDL CID resolverRDDL Authentication service to be able to authenticate with EdDSA to RDDL servicesThe configuration is set via environment variables such asLQD_RPC_PORTLQD_RPC_USERLQD_RPC_PASSWORDLQD_RPC_HOSTPLNTMNT_ENDPOINTWEB3STORAGE_TOKENRDDL_ASSET_REG_ENDPOINTCID_RESOLVERRDDL_AUTHAlternatively, the variables can be defined within the.envfile of the project. A exampleenv.examplefile can be adjusted and copied to.env.Service Executionuvicorn--log-leveldebug--reloadx21e8.main:appService deploymentIn order to deploy the service within an production environment adjust the user and group names if needed and execute the following commands:sudocp0x21e8.service/etc/systemd/system# that's the folder where main.py is located withinsudosystemctldaemon-reload
sudosystemctlenable0x21e8.service
sudosystemctlstart0x21e8.serviceCurrent state of Liquid Part:The liquid transactions are created the following way:Confidential Address DerivationA master key is generated from a mnemonic phraseThis key is derived once (1) and a child key is acquired.The child key is used to derive a liquid address....Through various steps a confidential address is created. This address is passed along the private key that was used to create the confidential address. This private key is not used anywhere. Apparently, the address is also not used anywhere.Asset Issuancetheissue_assetfunction is called which makes a rpc call in the background. The issue here is the confidential address created before is not used.where do we use the confidential address ? its not used anywhere elseThis part is solely handled by RPC calls.Is the trusted gw also make rpc calls ? or is it going to delegate this to some other backend service ?After we are done here, we get some kind of receipt for our transaction which will be used later on.Asset Id RegistrationThe asset id will be registered to our trusted domain.Is this a one time thing ? Are we going to use the same asset / token for every activity ? As far as i have understood, the asset issuer (r&c) does this only once.Asset Id Registration on Liquid NetworkThe asset id and the corresponding contract is registered on liquid as the final step.Is this also done only by (r&c) and done only once ?It seems like there is a confusion around creating/issuing an asset and actually distributing it to users. The steps here resemble a one-time asset issuance rather than asset distribution (which is called asset re-issuance.
Here is the official documentation :https://docs.blockstream.com/liquid/developer-guide/developer-guide-index.html#proof-of-issuance-blockstream-s-liquid-asset-registry.
The trusted gateway should ask for a re-issuance of token and this service should do it. The hw should focus on generating an address (from a mnemonic), post the planetmint tx first get the id from this tx and send it along the issuance request to the service so the service can determine how much token will be issued. Maybe its not like this and the issued asset represents a NFT on Liquid Network so for every create tx from planet mint there will be another asset issued on Liquid.