If you are asking about funding, investment, buying tokens etc then no, nothing like that is planned. This is a research project that can turn into a grassroots project if a community forms around it. The source code will be published under Apache 2.0. There is no entity that takes funding/investment or issues tokens.
If the HPL ever becomes a reality then I believe that a dedicated fee token makes sense that people can hold and use to pay fee. Besides that, another idea for an HPL-related token is to issue reward tokens to the users who pay fees proportional to the amount they paid. The reward token could then be used in governance or it could earn future fees if fees accumulate in excess of cycle cost. Anyway, as a reward token it would be held by users, not investors.
I understand that this is a research project, but how about making the native Token of HPL Cycle or Stablecoin? By making gas and fees paid in Cycle or Stablecoin, we can more closely resemble a real world ledger system.
Tokens can be used as rewards or points for each project or enterprise.
As web3, there is nothing innovative or novel, but surprisingly, it seems to me that you are looking for certainty, including scale as a ledger.
Some thoughts: The ledger may accrue excess fees over time that arenât entirely spent on cycles for its own operation. Do you really want such funds to be stored in cycles? There are already too many cycles floating around, thatâs why the price for cycles on exchanges is 20% of what it should be. I wouldnât like to add to this problem by charging fees in cycles.
Re. stablecoin there currently arenât any on the IC. When there are any then which one do you pick? We donât like to pick a âwinnerâ here.
In conclusion, maybe charging fees in ICP is largest common denominator here.
Is it really a problem that XTC is priced at a 70-80% discount to Cycle, and as demand for Cycle increases, wonât it go back to a pegged price between Cycle and XDR? Isnât this almost the same phenomenon as when the number of transactions in a chain drops, the native tokens as a gas fee goes from a corresponding decrease in importance to a decrease in price?
Iâm not sure, but Iâve never seen any other chain offer a fee that matches the value scale of the real world, so I feel it would be advantageous in resolving legal issues, etc.
I understand from your explanation that the throughput is such that sharding is not necessary, but I think it is important to be able to do it to differentiate yourself since sharding is an area that each chain is competing to develop. At the very least, it would have a significant marketing impact.
My understanding is that there is Sharding for multiple Ledger Canisters and Sharding for multiple Archive and Index Canisters. In the former case, would transactions across Ledger Canisters be asynchronous processing? Also, in the latter case, once it starts running, will it run out of capacity and have to be split and stored in Canisters or Subnets. Is there any way to counter these issues?
The archive (and index) should indeed be designed in a sharded way from the beginning. It will be split across multiple canisters and subnets. If enough subnets are available then it would not run out of capacity. But it would certainly be desirable if cheaper solutions come up in the future such as specific âstorage subnetsâ that donât hold everything on SSD.
Which issue exactly do you mean?
I am not so sure about that. How much has the IC benefitted from being sharded in terms of marketing? I would say 0. If at all it has made it harder to sell because people just used the sharded aspect to doubt the ICâs security or degree of decentralization. The IC would have benefitted more from launching earlier but not sharded. In retrospect the market for vertical scaling proved to be very big judging by the chains that captured it. And the market for sharded chains proved to be very small.
For HPL, I think the aggregator interface, which is what end users use, does not need to change when the backend migrates from a non-sharded to a sharded architecture. Therefore, I still see no need to invest time into sharding right now. It would be good to first see how the HPL is even being used and then based on that information look into sharded designs. For example, if the majority of transactions are simple transfers from A to B then that is easier to shard because it doesnât require locking (only refunds if a transfer fails). Atomic swaps are harder in the sharded setting because they may require locking. But we donât know if the more general types of transaction will actually be used to a significant degree.
Also, sharding will introduce additional latency in the transactions. Letâs first see if there is any adoption at the current latency before exposing users to even higher latency.
We do not know the deeper technical details. But I am wondering, if you save archives with multiple Canisters & Subnets, doesnât the lack of proof attached to Query calls and the fact that Composite queries are not yet possible between Subnets cause delays and make it difficult to use? Thatâs what I was worried about and thought it was an âissueâ.
As for Sharding, I understand. The market wants vertical scale rather than horizontal scale right now. But that doesnât mean we should ignore horizontal scale, and I hope that the design will take into account that enterprises that will need horizontal scale will enter the market in the future.
We are slowly releasing the HPL source code over time as the different components mature. A couple of Motoko libraries published on mops were actually part of the HPL project. In particular all of these:
enumeration is the data structure that maps userâs principals to internal numerical user ids. It is based on a modified RBTree.
vector is the data structure that holds all user accounts. Looking up a subaccount or virtual account, if the internal user id is known, happens in constant time.
swb is the data structure that is used in the sliding window buffer protocol for queuing and batching in the aggregator.
Today we are publishing promtracker which is a library used to collect metrics during canister operation, aggregate and process them, and export them in prometheus-compatible format through an http endpoint. There they can be scraped and written to a prometheus database, for example by the light-weight grafana-agent. We use this to produce all the graphs on the dashboard. For example, the library automatically captures high and low watermarks over a configurable interval as well as histograms over time which can be used to generate heatmaps.
Regarding Link, from the R&D demo it looked like it would prevent misdirection. If a link is created with a fictitious address/account or a copy and paste error, wouldnât it be possible for the sender to pull the link if the recipient doesnât exist or doesnât want to touch a link they donât remember? If so, this would be a solution to the blockchain challenge of irreversible transmission.
Correct. A link is personal for you, that means if you can push to it then, by definition, you also have access rights to pull the funds back from it. That is, of course, unless the receiver actively reduces the linkâs balance (i.e. âacceptsâ the funds). The key here is that the receiver must be active after your push. This prevents loss of funds in various scenarios, mainly the scenario where the receiver has lost his keys after setting up the link or even after you pushed the funds, or where the receiver has disappeared (e.g. shut down his service).
Some of the other things you mentioned are indeed prevented as well, but already earlier, before it even comes to any transfer. For example:
a link with a fictitious account cannot be created in the first place,
when you make a copy-paste error then the resulting link code is unlikely to 1) exist, 2) have access for you and 3) match the asset id that you are trying to push it,
the receiver cannot forget a link because a principal can always query the ledger for all its links
HPL tries to prevent loss of funds also in other ways, not only ones related to transfers. For example, it is not possible to forget your âsubaccount idsâ or to forget which assets you held. A principal can always query the ledger for all its accounts in all assets.
Do you have any concrete plans for utilizing HPL as a ledger in the future? For example, we would like to see ckBTC selected as the reserve currency, forming an ecosystem that includes BTC-related tokens, etc., or partnering with credit companies in stablecoin.
Hey @timo . How is it going? Are you able to make progress and work on this? I recently daydreamed about the HPL With the Solana transaction failures at 1k TPS, it would be sweet to showcase that you can build a better version of Solana tech on ICP. 10k TPS for a blockchain is getting close or surpassing the web2 equivalent payment rails. So it would be a big deal and great marketing for ICP.
The HPL is usable. It has been presented in the February 2024 Global R&D as a demo. The wallet is accessible at https://wallet.hpl.live. However, the deployed version is still a test ledger. It can be wiped at any point in time. For the real, permanent ledger two things are missing: 1) governance, 2) separation of âownersâ from principals.
When the permanent ledger is deployed then it is unclear who manages updates and how. That is an open question. Some form of governance has to be developed.
Currently, you cannot ârotateâ your keys, i.e. all your accounts and virtual accounts are bound to the one principal that you used to create them. Historically, in other ledgers, this has been fine. If you have a Bitcoin address and want to update your keys then you move your funds to a new Bitcoin address. But itâs not so easy in a multi-token ledger anymore. If you are holding many different assets, have set up many subaccounts for different purposes, and on top of that have created many virtual accounts (allowances) for use with various services then it is not so easy to re-create the entire setup under a new principal and to move all the funds over. Therefore, we should think about an indirection from principals to owner ids where the principal can be updated without affecting the owner id.
Work on these topics has not started yet.
Re. 2) If you use a wallet frontend hosted on a particular URL and you log in with internet identity your principal is bound to that specific frontend URL. You cannot take that principal with you to a different frontend hosted at a different URL. If you would like to switch to a different frontend or if you are forced to because the old one has disappeared then you are out of luck. That is one of the biggest reasons that an indirection is required. The problem is specific to internet identity and related login methods such as NFID. If you use SiWE or paste a mnemonic phrase directly then you can take your principal with you. So it is not entirely clear that the ledger has to solve this problem vs II has to solve this problem. But currently I am thinking that enabling key rotation has many benefits that it would be worth doing.
Re 2. If the principal used to identify the owner of HPL account belongs to a canister then the principal used to control the canister can be changed; wouldnât this provide the necessary indirection where required or desired?
At the expense of deploying and running such an HPL-account-controller canister per user.
damn it kinda disappointed
With the Solana transaction failures at 1k TPS, it would be sweet to showcase that you can build a better version of Solana tech on ICP. 10k TPS for a blockchain is getting close or surpassing the web2 equivalent payment rails. So it would be a big deal and great marketing for ICP.