Submit Cryptex Proposal #1660
Submit Cryptex Proposal #1660
Conversation
|
|
|
Thanks for the interesting application @driemworks and apologies for the delay. This seems like an intriguing protocol. I will mark your application as ready for review so the rest of the committee can comment. In the meantime, I will also ping my colleague @dsm-w3f since you mentioned he expressed doubts about the previous design. I will also ping @burdges in case he is available to take a look at this design. |
|
Hello and thank you @driemworks for your proposal. I was asked to provide some help to review this. I have a curiosity: I am aware that https://eprint.iacr.org/2021/005 exists, it's more recent work than https://eprint.iacr.org/2019/985 on which the proposal is based. But also some of the features mentioned in the proposal are already covered to some extent in https://eprint.iacr.org/2021/005 such as VUF (which is related to VRF), plus some additional features such as aggregatable and publicly-verifiable transcripts (these features may be desirable too). Overall, are you aware of this research? If so, what are the advantages of the older work (2019) than the newer one (2021) that made you chose to build on top of the 2019 construction? Also, you may have a completely different use case in mind (unfortunately I am not familiar with all the Polkadot components) but, for example in https://eprint.iacr.org/2022/1205.pdf (last paragraph of section 2.4.1) we explain what are the downsides of threshold signatures and DKGs. For me (I may be wrong/missing something though), a motivation as to why a DKG is needed for Polkadot in the first place would help. Thank you. |
|
@InaOana thanks for the feedback. I wasn't previously aware of the 2021 paper you linked. I've done a brief read through and have noted some of the major distinctions between the two approaches. The scheme proposed there is really interesting, and I agree that PVSS is worth exploring. Our proposal uses keys in the finite field rather than in G2 like in the 2021 paper. It also relies on a verification and disputes phase using zk proofs, which the 2021 paper is able to avoid through the use of their VUF/transcript verification process, resulting in an overall more efficient protocol. The 2021 paper also relies on a p2p gossip protocol, which we could potentially accomplish using sc-network-gossip (maybe?). There is also an implementaiton of the 2021 paper already existing, though it hasn't been modified in a while. From my perspective, since we are operating on a 6 month timeline with this proposal (dkg + pallets + sdk + ui + etc.), the additional work required as part of the 2021 paper is somewhat beyond our scope for the time being, though it introduces concepts that we would like to explore. I think that since our proposal is not consensus critical, the p2p gossip layer would probably add significant overhead, though I haven't done a proper analysis of that. Interestingly, the paper proves the security of Feldman/Pedersen VSS, which our scheme is based on. As for https://eprint.iacr.org/2022/1205.pdf, this doesn't exactly reflect our use case. I did make a mention of maybe looking into something along the lines of HoneybadgerBFT, which could possibly fall under that categorization, but we have no plan to implement that as part of this proposal. Our proposal has no (or, at least only indirect) impact on the underlying consensus mechanism, and is not consensus critical. Rather, the proposal is really trying to be consensus-agnostic. We're proposing a decentralized KEM where the shareholders are only a limited subset of validators, and there are many subsets of validators who could simultaneously be participating in distinct rounds of the blind dkg protocol (in our proposal this is based on stake and they do get rewarded/slashed because we plan to use a PoS consensus, but failure of the KEM will never result in failure of consensus). The broader use cases we have in mind for this are related to threshold signatures/wallets and rule-based secret sharing (e.g. data access (decryption rights delegation) based on ownership of a specific asset). In the future, we would like to explore using XCM as a way to enable cross-chain secret sharing (e.g. Cryptex is used to derive a distributed key and data is encrypted with it, then a 'rules' contract is deployed to Moonbeam, which can send XCM to Cryptex to request decryption). When originally coming up with this proposal, we did have a consensus-based approach in mind, however we pivoted to more of a 'parallel staking' approach, where authorities (regardless of consensus system) can provide some type of collateral to be able to participate in the blind dkg mechanism. Theoretically, our protocol does not need to be a blockchain. It could be implemented on any p2p network, but using a blockchain provides a lot of nice properties for making it 'unstoppable'. |
|
Thank you @driemworks for the detailed answer. I have no further questions for now. I believe though the assigned reviewers should have the final say in evaluating this proposal. |
There was a problem hiding this comment.
@driemworks thank you for submitting the grant proposal. This is such a complex system with many technical details. Developing and ensuring the correct implementation of all concepts involved would need a huge effort. My first concern is how you plan to assure the quality of the final product. Are any automated E2E tests planned? What is your quality plan?
The most common use cases when key sharing is needed for Dapps is solved by Multisg wallets. Furthermore, it is possible to use MPC wallets that solve many problems that you mentioned in the application. Are you aware of the existence of Jade Wallet? It works with Polkadot and it was supported by the Kusama treasury. Can you compare your solution proposal with Multisg and MPC wallets and explain what problems it can solve that cannot be solved by these two other approaches?
Of the related projects that you mentioned the one that make me search more about it was Lit Protocol. It is a well-funded company with some pretty good use cases, such as Lens protocol. This shows that there are good projects using related topics. However, Lit is a big player. What if they want to join Polkadot/Kusama ecosystem, how your solution would be different or better than them? They support many blockchains but not us.
|
@dsm-w3f thanks for the reply. I'll update the proposal shortly to include some of the details in this reply:
It really is, and the team is prepared to fully commit to this once approved. We've also reached out to the delivery services team at Parity and shared our docs (so far) with them for further advice on how to best accomplish and manage everything given our timeline. Additionally, we're in communication with Nico from square one. We would be happy to hop on a call to further discuss the details and diligence required for this work.
Yes, we do have both unit, manual, and automated end to end tests planned. We intend to meet a minimum coverage of 80% on all code, as well as document manual test scenarios + zombienet scenarios, and to integrate code coverage and quality tools into our CI pipeline. Here is our testing tools/plans in brief:
Once completed, we will have security audits performed on our codebases as well (and resolve any issues of course).
I was not previously aware of Jade. It seems like an interesting project, but they rely on centralized servers, and it only works with iPhone/iCloud, which is a wide audience but still limited.
Since our system is intended to provide access to secret data (by providing rule-based access to secret key shares), multisigs by themselves are far too rigid and could be a bottleneck, thus the requirement for a threshold to make the system more flexible. As for MPC wallets, our proposal shares a lot of similarities (the 'secret society' idea is basically a blind MPC wallet) but one main difference is that the shareholders in our system are meant to be secret (blind), which is not generally the case in an MPC wallet, as well as privacy preserving when requesting reencryption keys (I'll update the proposal shortly with more info on that, we've done a little more researching while awaiting review). Our proposal is completely decentralized, unlike some MPC wallets. Our proposal's ultimate aim is to build a runtime and sdk that can support decentralized secret sharing without "linkability" between the secret share, the shareholder, and the data being secured by that key. I think the proposal may have been a little too open ended when trying to say this, so I will go and update some of the language/protocol to better reflect that statement. It does not need to be implemented as a set of pallets, it could probably be a set of contracts honestly, or maybe not even need a blockchain (e.g. LIT), but when implemented as pallets it makes it easy to make secret shares backed by stake, so the network can be further decentralized/trustless. Since we want the network to act as a decentralized KEM, we want to be able to reward/slash based on participation in the DKG as well.
I was actually really surprised they had no support in terms of Polkadot/Kusama, since as you said, it is well-funded and there seems to be active development. It seems they only support ECDSA keypairs for now, which is most likely why they haven't. Functionality-wise, we do have similar capabilities as Lit, though I think our approach and implementation is quite a bit different. LIT does use DKG + TSS, but there's no mention of any privacy-preserving aspect, or blindness, to this. In reality, the idea of using a DKG like this has been done many times before, as seen in LIT, ethDKG, etc., however, the big contribution we're making is the blindness.
Competition is healthy and monopolies are bad. One of the major differences is that LIT is not a blockchain (it's middleware) and not fully decentralized (their docs even put a '*' next to decentralized), whereas Cryptex is a blockchain and is fully decentralized. LIT also distributes keys to a large set of nodes (one to each of their equivalent of 'validator') as per their docs, which to the best of my knowledge is mostly static. I think this could potentially be a performance issue for the network as it scales. Our protocol doesn't need to distribute keys among the entire validator set while still benefiting from the network security granted by validators' stake. Since they have keys distributed to all validators, who are publicly known, I feel like that is a vulnerability (bribes, anyone?). Apart from that, another difference is that this team has a lot of experience working with substrate-based projects (Polkadot blockchain academy and previous projects) and on substrate itself (Juan is at parity). If LIT were to move to support ed25519 keys tomorrow, then we might face some crisis (could they do this with some type of adapter signature?), but otherwise I think if we can get development underway soon and if we can receive support/feedback/criticism from the community, then we would be OK. Our protocol has some attractive features not available in LIT, for example: Cryptex is a blockchain (LIT is not a blockchain) and it's substrate-native which gives us the opportunity to secure our network with a relay chain (LIT can't do this at all), and we can also use XCM to have an owner and recipient of secrets be on distinct chains in the future. We should also pretty easily be able to work with other parachains (assume we get that far), for example working with Invarch to enable IP protections or Ajuna to manage ownership of in-game assets (e.g. a p2p marketplace for owned in-game items, secured by Cryptex). |
|
Are there github links to past real crypto work by team members? You want a DKG for BLS signatures? Did you consider any of the non-BLS schemes with better DKGs?
I've not looked into the whole proposal here but.. In polkadot, we select participants by their own VRFs in parachain approvals, but this works because someone is already on the hook for the block to be valid. If you pre-select a committee this way then they'll have the usual concentration of malicious actors problem. There are solutions to this using concentration inequalities, ala Byran Ford's OmniLedger paper and our multi-relay chain proposal, but you need to elect like 1000 nodes to claim 2/3rd honest, given an ambient assumption of 80% honest. I suspect most blockchans with some subcommittee system wind up not meeting their security goals for this reason. As DKGs are sensitive form both sides, if you run a DKG then you should probably run it among all nodes elected by stakers, and simple accept that you need a better DKG if that's a lot of nodes. Or go the non-capitalist route for participant selection like https://drand.love/ |
Appears you want encryption to the DKG not signatures? This might explain your DKG choice, but you didn't say what I'd have expected there. Also, there are other DKGs which can somewhat be used with encryption, albeit less nicely. |
I have a background in mathematics, but no, the team does not have any specific experience with writing production-ready cryptographic functions or published papers (though we are working on that). I previously worked on a w3f grant to try to introduce a threshold scheme repo here, but the scheme laid out there presents a lot of vulnerabilities, which this proposal attempts to resolve. We've worked on web3 projects previously, including on substrate and substrate-based blockchains, but I'm not sure if that's what you're looking for. @carloskiron is currently taking a course on zero knowledge cryptography. I've started playing around with implementing my own DKG using arkworks here.
We chose BLS for the same reasons outlined here, mainly that it works nicely with groth16. We're not necessarily married to BLS signatures in the case that we don't use something like groth16. Can you clarify what 'better' implies in this context?
There are some alternate approaches to this that we have considered, maybe you can provide some guidance/clarification. With what's written in the proposal, my thought process was that by using the VRF output as a condition for participation if it's within a given range, then we should be able to fairly randomly select the participants in the dkg, and to be able to verify valid participants, no? After that, if a participant is malicious and issues invalid shares or fails to participate, then they can be slashed and booted from the protocol. If it is not the case that this would result in a 'blindly selected' committee, can you point me in the right direction? I've also started exploring using blind signatures as part of the scheme, but it would require some changes and further analysis (I can share offline if interested, I think it provides a lot of really nice properties).
That's pretty scary.
That's an interesting point, we'll start looking into this. By better here, do you mean able to handle a very large number of nodes? It would be pretty straight-forward to modify the scheme to include all nodes instead of some. My concern with relying on a secret shared by all validators for each round of the protocol is of course a scalability issue, simply because it adds more communication overhead as the network grows and has to prepare and verify a larger number of proofs. A previous version of the proposal, that we trimmed down to this, had an initial phase where validators chosen to be active in the next session participate create a session secret/public key during the session planning phase. Then, during the protocol, each shareholder encrypts shares using that session public key and at least a threshold of validators would need to verify the VRF output and reencrypt the secret key share for another valid participant. We removed it because it's a lot of added complexity, but if interested I can bring back those details for review.
We'll revise some portions of the proposal and try to clarify that, along with the clarification suggested by @dsm-w3f . |
|
Anyways.. You want to encrypt in some way so that decryption occurs in the future. Your DKG is an optimization that avoids users encrypting to multiple parties. Yes? |
We want to encrypt data with the shared pubkey from the dkg, and then ask them to provide reencryption keys in the future.
The optimization is so that it's hard to associate any given shared secret with the set of participants that made it. I'll push an update to the proposal tomorrow to elaborate |
|
You want to reencrypt again in the future, not decrypt publicly? Why? You'd normally expect public decryption within some date range suffices, so what is the ultimate service being provided here? |
|
I just updated (you could almost just say rewrote) the proposal, I think it should provide a lot more clarity now on what we want to accomplish. There are two major things we want to deliver: first is a "blind dkg" implemented within the runtime, and secondly is a rule-based secret sharing platform built on top of that, which we do using the shared keys held by validators. I also wrote a substack post that discusses the blind dkg I have in mind. |
I've not read everything but this statement feels "dubious" to me. In practice, anonymity tools like Tor and consensus tools like blockchains make a trade in which less privacy for the node operators gives more privacy or security for the users. It's not "wrong" per se, merely tricky to quantify, and extremely opsec dependent. I've discussed ideas for a "border crossing wizard" within a mixnet with other cyperpunk friends before, but we envisioned doing this within a messanger, or even a mixnet based messanger. As soon as you say blockchain then your asking "how do we ensure this from a 2/3rd honest assumption on the nodes." Blindness makes this hard. Did you read anything about our upcoming Sassafras protocol? It's a secret single leader election (SSLE) protocol that builds a schedule of blocks from "tickets" anonymously signed by collators or validators using a ring VRF, with the ring VRF output being sorted to produce the exact schedule. In sassafras tickets, there are two ed25519 public keys not essential to the SSLE role: The first we use to sign the block, and then we destroy its secret key, which provides forward security. You could also use this key as a Tor .onion address, or mixnet address, to talk to the block producer before they make their block, which avoids the memepool. The second is derived from a secret key that is the output of another VRF you public when you make your block, meaning everybody learns this secret when we reach this point in the schedule, or else that validator fails to earn those 19 DOTs. If you encrypt some data to a few different future keys then once they all get revealed then the data becomes public. Now this second does not have such great security properties, like some validators learn the secret first and could choose not to make their block. It's really cheap though since we need sassafras anyways. Have you considered what sort of user experience you'd want on your blind DKG? Would you be interested in building a tool that does roughly the same thing, but with this weaker but simpler and cheaper underbelly we'll be building anyways? You could still play with the more symmetric side of the crypto. See https://eprint.iacr.org/2020/800.pdf or https://github.com/SpinResearch/RustySecrets or https://github.com/topics/secret-sharing Or maybe https://en.wikipedia.org/wiki/PURB_(cryptography) and https://arxiv.org/pdf/1806.03160.pdf and https://github.com/dedis/purb |
|
Hi @driemworks, the technical discussion seems pretty hot here, which is good. @burdges and @InaOana thank you for reviewing this work and for your wisdom comments. I think there are doubts if the "blind" property in DKG is well defined. In this case, would be better to define and prove that this property will work and how from a theoretical perspective before developing it. The appropriate approach for that is to write a paper with the theoretical description and submit it to the review of cryptographers in an academic/technical venue. This is out of the scope of W3F grants program and could be held elsewhere. However, from a business perspective having DKG in our ecosystem would be nice. As far as I know, we don't have it available as pallets or ink! smart contract ready for use. I think if you remove the blind property for your application it could be a more solid one since you would develop well-proven properties and your application is still interesting since we don't have it. Furthermore, if you have the same or near features from Lit Protocol would be easier to attract projects that use them to our ecosystem. @driemworks what do you think? Would be interesting to you and your team to change your proposal in this way? |
|
I believe some https://github.com/kobigurk/aggregatable-dkg variant could handle encryption of single messages to a public key previously generated by its aggregatable DKG. An aggregatable DKG scheme lacks infinitely parallel decryption via IBE like with the worse classical DKGs you cite, or Jen Groth's DKG in https://eprint.iacr.org/2021/339, or the VDF discussed by Luca and myself in https://eprint.iacr.org/2020/638 You guys mentioned BLS but seemingly never realized why BLS helps via IBE. You seemingly want individual message decryption upon demand, so likely the aggregatable DKG works fairly well in your case. An aggregatable DKG scheme should be simpler than what you envision, although not as simple as sassafras. It incurs costs because all nodes must sign multiple messages when finalizing the block, and your parachain needs this finality layer before collation, but you'd pay this costs anyways. Anyways.. I'm definitely pro outsourcing the UX for encryption to the future, but it should work with the cheap scheme already planned for sassafras. I'm broadly pro funding work on the aggregatable DKG for usage in polkadot, but right now I'm not convinced you guys thought through everything. Academic papers often promote and analyze protocol which wind up inferior, or even redundant, mostly because computer scientists frankly suck at analyzing the larger design space in which they work. I'm pro supporting a "boarder crossing wizard" but not entirely sure how we'd sell it as polkadot related and afaik it needs messanger not a blockchain. If you do want to prove the utility of your blind DKG then I'd suggest you first think about it in that context. |
We're open to making changes. I still think the idea regarding blindness is interesting, but to @burdges point, even though the math works out it might not be the same in practice and I'd hate to get bogged down by novelty. As long as we can accomplish something roughly the same (general rule-based secret sharing as first use case), we are fine with changing the design.
I think that could be an interesting approach and could probably help us move faster. I'll need to read more on Sassafrass before I feel able to give a definite answer though. I found this to read through. Are there any other docs regarding this I should also read?
If we do go down this path, would we be able to get some advice on SDK design so that it would work nicely with sassafrass? I think that could be needed for the proposal.
@InaOana also had a similar statement on this before I made my updates to try to add blindness. On having thought through things in regards to the aggregatable dkg, that's mostly accurate. I will be traveling over the next few days, but I should get a chance to read through the paper and code and determine a plan/implementation for bringing it into a runtime. Are there any specific issues or aspects that might not be very obvious or which were lacking that you think I should look out for? Our goal is to convince you. Just to recap: |
|
@burdges @InaOana I've read through the Sassafrass paper https://eprint.iacr.org/2023/031.pdf and wanted to run a few things by you guys before I make any changes: Is my understanding correct that we would be able to leverage the SASLE defined in section 4 to perform the participant selection (i.e. kth leader is kth shareholder)? And a followup to that, is if the implementation is complete or if we should scope out any development tasks in that regard? Does it seem like a reasonable approach to also incorporate the ideas of the aggregatable DKG https://eprint.iacr.org/2021/005.pdf, where a transcript is submitted along with each ticket? Is this on the right track? |
|
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/cumulus-consensus-modules/2896/12 |
|
This is starting to come together for me, no longer using a DKG is a big departure but it makes sense. If we use a threshold IBE scheme in aura over BLS12-381, without nugget BLS (since we don't really have any other use for the key, so as you say hash-to-g2 makes the most sense), then we should be able to have a simple EtF, though I want to investigate something more ambitious like https://eprint.iacr.org/2021/1423.pdf as well (though that is probably far out of scope). I will need to do some more analysis before making an update to the proposal, probably mid-week. High level and tentatively, my thoughts are that we will use a TIBE block seal in Aura (maybe Waters ?), determine a mechanism to select the future block seals/roles to encrypt to, define a rule-based decryption condition system, and logic to collect ciphertexts + decrypt, along with the SDK and other non-dkg items that were originally planned. |
|
You can see it'll all be a lot simpler now, yes? You'll still need considerable rather specialized code here though: User agents must grab the aura block producer list and compute the schedule. You already need this code in your host and runtime, but your user agent needs a more advanced lite client (smoldot?) because:
You should select which future slots you encryption to, and hence when decryption happens, not really sure what's best here. It's kinda threat model vs convenience. I suppose some configurations like 2-of-3 simplify the crypto vs k-of-n, but it's likely you'll want to adjust this in future. |
|
Send me another invite to your matrix room, not sure why the previous one failed. |
|
Hi @driemworks, could you give us an update on the current status of the application and/or your discussion? |
|
Hi @semuelle, the proposal is ready for (re)review. After the discussion, above we made significant changes to the proposal and reduced the scope somewhat. |
|
@driemworks thanks for updating the proposal. @burdges when you have time, could you take a look again in this proposal and provide feedback regarding the technical aspects of it? |
| #### What this is not | ||
| - this does not use a proof of stake consensus. For the scope of the proposal, we are assuming a static, well defined validator set using PoA consensus based on Aura. | ||
| - the proposal does not highlight any specific privacy preserving tools nor does it use threshold signatures or any specific MPC protocols | ||
| - most of that is scoped for the future though |
There was a problem hiding this comment.
This is more a substrate concern of parity not having made proof-of-stake easily available yet. There is nothing really wrong with using proof-of-stake here, but like VRF protocols you need to know who'll be the nodes before chosing the session id, or at leaast before the users use it. Nothing wrong here, just observing.
There was a problem hiding this comment.
I left the comment in for now, just so we can lay down expectations/scope
applications/cryptex.md
Outdated
|
|
||
| https://docs.rs/sc-consensus-aura/latest/sc_consensus_aura/ | ||
|
|
||
| We will create a fork of Aura, wherein blocks are sealed using identity based signatures, where each slot has a role associated with it. |
There was a problem hiding this comment.
An IBS is something else.
This is just a DLEQ proof of a BLS signature on the slot seed, computed similarly to Babe. The DLEQ proof contains a Fiat-Shamir transform, which can sign the block, just like Schnorr.
It's possible to have a separate Schnorr signature which signs both the BLS signature and the block, but checking a BLS signature is slower than checking a DLEQ proof of a BLS signature, so not much point.
Anyways..
The BLS signature on the slot seed is the extract operation from IBE.
applications/cryptex.md
Outdated
| The winner of a slot $s$ calculates a secret key corresponding to $Q_i$ and uses it to sign the block. The winner calculates a signature as $S = s_i \hat{Q}_i + r H(M)$ and $T = r P$, where $M$ is the block hash, $s_i$ is the secret distributed by the coordinator, and $r$ is randomly selected from $\mathbb{Z}_p$. We implement this within the Aura client code. | ||
|
|
||
| **Validation** | ||
| When other nodes import the block, they validate it by calculating the ID for the slot and calculating the public key $Q_i$ and verifying the signature. We verify the signature by checking the pairings: $e(S, P) = e(Q_i, P_{pub}) + e(H(M), T)$. This validation logic will be executed each time a new block queued for import is validated. |
There was a problem hiding this comment.
It's more efficient to verify this without pairings, using a DLEQ proof, like I did above.
S_slot = s_i Q_i is the slot secret key, revealed when making the block, although using i for both subscripts here gets confusing. sine the s_i are really fixed for each collator, aka s_collator.
Signer:
r <- /dev/urandom
R_1 = r G_1
R_2 = r G_2
c = H(R_1,R_2,pk,S_slot,blockhash)
pok = c s_i + r
Verifier:
pok G_1 = c pk_i + R_1
pok Q_i = c S_slot + R_2
This proves pk_i = s G_1 and S_slot = s Q_i for the same s. These G_2 scalar mults are not much faster than the miller loop, the they avoid the even slower final exponentiation.
I can show you later how to do this easily using the dleq_vrf crate.
There was a problem hiding this comment.
That makes a lot of sense, I updated the proposal to reflect that (both sealing and verification). I still have to update the etf_aura.pdf overview to include that; I'll commit that soon.
|
These guys seem to get the picture. I can help them on a few small bits. Also, this is much simpler than what they'd originally proposed, so more likely they'll actually manage to deliver. I'd say go for it |
There was a problem hiding this comment.
Thanks for the updates, @driemworks. Sounds good to me. You added a file with the last commit. Could you remove that?
|
|
||
| | Number | Deliverable | Specification | | ||
| | -----: | ----------- | ------------- | | ||
| | 1. | Smart Contract: Auction Contract | We develop a smart contract (and host it on our blockchain) that enables an on-chain auction where participants can issue a sealed-bid which will unseal at some specific future slot. The sealed bid is stored in the contract. | |
There was a problem hiding this comment.
This is written in ink!, I assume? That means your chain supports the contracts pallet?
There was a problem hiding this comment.
Yes, written in ink! and using the contracts pallet. I didn't include it explicitly, but as a basis we'll use Grandpa, our modified Aura, Contracts, Balances, Timestamp, insecure-randomness-collective-flip, and possibly the Assets pallet if we see a need (for the final milestone).
|
I removed the file, not sure how that snuck in. |
|
Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions. |
|
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/sponsorship-for-sub0-thailand-2024/10093/19 |
|
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/sponsorship-for-sub0-thailand-2024/10093/38 |
Project Abstract
This proposal presents a blockchain that uses a modified Aura that seals blocks using identity based signatures (BLS). We then implement an encryption-to-the-future (EtF) scheme, where messages can be encrypted for arbitrary slots in the future. Our proposal consists of a runtime, which modifies Aura and introduces a new pallet to enable the identity based cryptosystem (IBC), a light client, and an SDK which handles synchronization with the blockchain, slot scheduling, and offchain encryption and decryption functionality.
Grant level
Application Checklist
project_name.md).@_______:matrix.org(change the homeserver if you use a different one)