It's better than hogging up the ledgers with ephemeral data, until we get some Coda Protocol-like ZKPs for removing the need for historical archives?
Also, off-chain isn't limited by the same transaction speeds that on-chain is.. I.e, having to wait for a ledger close.
I get why on-chain seems attractive, but it's just a mirage.
Well, I can tell there's truth in your ideas but dismissing the whole project that way seems kind of a light behavior to me.
It should be seen that both ways have their own benefits and that on-chain signature sharing could clearly be the best solution in some cases.
Once again you're simply making the affirmation that it shouldn't be tried at all, but without any kind of convincing demonstration. (How could it be a mirage to start with?)
I don't have better arguments for it right now, but it's based on years of thinking about this, and writing multi-sig code on Stellar.
The transaction system in Stellar is something I find very elegant. It's very expressive, and very powerful, for what it does.
The way you can have multiple parties come together in one transaction, and do things atomically in one go (OTC trades/swaps/shuffles, e.g.), which would in other systems take multiple rounds of carefully thought-out transactions.
The way you bundle operations into atomic packets, where every operation has to succeed, and how you can do conditional transactions using that.
The way signature thresholds and signing weights can be use to express much more complex schemes than just your regular old n-of-m.
The way user specified signers sign for accounts, and not necessarily just the private key corresponding to an account.
Somehow signature aggregation didn't make it into the system. I think it should have.
I've seen systems where you post a transaction on the chain, and then signers post their signatures on the chain, and when a required number of signers have signed the transaction is executed.
Stellar decided against a solution like that, and I'd agree.
Signature aggregation is messaging about transactions.
I guess I'm a bit of a purist here, but I think that is something that is better taken care of off-chain.
First of all, you have no bloating of the ledger with ephemeral data. A proposed transaction is only live until either the transaction is accepted by enough signers (and subsequently published), or until it's cancelled (manually, or by a time out).
Not having to worry about data sizes also brings you a lot more flexibility, and security; You can encrypt proposed transactions so only the signers can examine them, sending each signer an encrypted blob only they can decrypt.
You're not dependent on ledger updates for disseminating information between signers, so your information flow is a lot quicker.
No complications with sequence numbers
I think what ought to have been done, is for signature aggregation to have been integrated into the Horizon service.
Since that didn't happen, the second best thing is having a 3rd party decentralized network for off-chain signing, working in the same way.
Decentralized networks aren't anything new, we know how to deal with them. You'd get some amount of people to run nodes, and have clients remember a number of nodes they have been in touch with + a couple of seeds. The nodes make sure to synchronize transaction proposals, signatures, and signing requests.
Again, ideally that would have been part of Horizon, to get things working seamlessly.
I think elegance is worth striving for, and that's why I'd go off-chain anytime. On-chain is like putting lipstick on Mona Lisa.
dzham I agree that horizon would be a perfect place for it. I also sometimes feel, that we need multiple horizon-like implementations, focused on specific use case, instead of trying to do payments + trading + every other use case.
What are you currently working on? Is it some kind of API we should all host?
Thank you for this complete answer. It helps me thinking about it.
I totally agree that this should be implemented in horizon as well.
I think the first official reason not to do that was to preserve ressources.
However, alternatives use more ressources or are redundantly implementing a side-network. So this "pushing outside" the problem can't really lead to a satisfying solution.
Making a side-network have the main issue of not having the same level of trust and security than the blockchain itself, making the feature half-implemented. For this reason, I think we should not aim for such solution on the long term.
Putting data's on the block chain is like using validators network, except the data are not cleaned after being used. This is cumbersome and doesn't makes much sense. For this reason, this should not be the final solution either.
Hopefully having a less-than-optimal solution running on the blockchain will show that:
The storage issue may then push the dev to implement it properly in horizon, if the system proves usefull.
Of course this is pure speculation. I'm only trying to clarify my views about it.
I mostly agree with what you said. I still think the on-chain solution is a desirable fallback solution for a lot of users. I would say your rationale seems to make more sense from a developer point-of-view; Meaning: if they had to choose, lot of users may prefer a full on-chain solution than a split system, even if it is not optimal as a design.
I can tell people with high-speed automation would need something another network, though.
MisterTicot I still think the on-chain solution is a desirable fallback solution for a lot of users. I would say your rationale seems to make more sense from a developer point-of-view; Meaning: if they had to choose, lot of users may prefer a full on-chain solution than a split system, even if it is not optimal as a design.
My fear with that, is that most people would find on-chain good enough (because it is good enough for everyday use), and then we won't get the benefits of something more scalable, faster, etc. It's all about interoperability in the end.
umbrel I agree that horizon would be a perfect place for it. I also sometimes feel, that we need multiple horizon-like implementations, focused on specific use case, instead of trying to do payments + trading + every other use case.
It's hard to make a one-size-fits-all solution. Even for basics you sometimes have to go over the bridge for water.
It doesn't do everything I need, I know that. And it's starting to become quite bloated, in terms of the default returns.
The GraphQL PoC that was made wasn't such a bad idea, it just needs to be able to support more kinds of queries.
umbrel What are you currently working on?
Nothing tangible. I have the centralized version (https://constellation.futuretense.io/) running since a year or so, and I have lots of thoughts and sketches. I never went further because there just didn't seem to be any interest. The only people talking multi-sig, for years, were me and sacarlson.
Is it some kind of API we should all host?
That's the idea. We get a number of people to host servers, and we publish a couple of seed nodes.
I'm not sure how many would be enough. There aren't really any security issues -- it's about availability, and not having a single-point-of-failure.
If it has to be on-chain, what would be your take on using testnet (or a private network) for signature aggregation?
I thought about this solution also. The issue with it is the same than side-network: it's simply not stellar anymore, meaning you don't have the same security and guarantees. Especially on testnet.
Now, having several of us running a private network for this purpose could be a form of solution. I would not be so happy about it though, because it seems like settling durably for the low-grade solution. I don't know if you get what trouble me here.
I mean, multisig is not a secondary-level feature, right? It's in the core of the design now and it deserves to be implemented right. Now, if we put in place this kind of community-driven fix, don't we give a mandate to never make it right?
Maybe it would help to have @jed or someone from Stellar team commenting on this one ?
Maybe.. In the meantime I'm working on an off-chain solution, using ipfs pub/sub for synchronizing hubs.
I would not be surprised at all if this is something that would be accepted if we put the work into adding it to Horizon and did a PR. I would be surprised though if this was something that SDF were planning to work on themselves — I just don’t see enough demand for it yet. The people who have encountered and understand why this is a problem probably aren’t much more than the people in this thread already.
With that said, if we can come up with some tangible plans for how to implement this I’d be more than happy to help code it.
If I talked golang, integrating it directly into Horizon would be my first choice.
It's not just multi-sig though, it's bigger than that. The same messaging rail could be used for regular transactions also, instead of SEP-0007:y links, or QR codes.
I'm reading up on distributed logs, which is basically what this is.
For signing requests you have four types of messages (signed by end-user, and verified by the hubs),
and these get replicated throughout a network of hubs, where end-users can connect to any hub in the network.
All state can be recreated from the message log. If we let requests have a (say) 24h expiry, logs can be trimmed to only include messages that relate to open requests, making log catchup quicker.
It looks like a specialized ledger on which you can delete entries. So I guess that somehow most of the code is already in there (stellar core).
There would be two kind of data's in there:
- Unsigned transactions that need to be shared between signers. The deletion condition would be "outdated " sequence number.
- Signatures for a given transaction (referred as a txhash - we don't always need to share the transaction when we share the signatures). The first deletion condition would be on transaction approval on the blockchain. If the reference transaction is known, the second deletion condition would be when sequence "outdate". If not, it could be time-based. Hence, smart-contract reliying on publicly available signatures are supported even it takes 10 years to resolve. An additional condition for removal could be if enough signers declare they won't sign a transaction (in which case we need to record in the editable ledger when user decline to sign - which is an interesting feature that could actually save ressources and allow the time-based condition to be softer).
This service should incur a fee anyway to counter spam.
I can't get how it would obsolete SEP0007. In my mind this scheme would only allow to share signatures/transactions between the actual valid signers . If you allow transaction request from any arbitrary peer, you open the doors to crazy spamming. Please note that a particular peer can be added as a signer with a non-determining weight to be allowed to send transaction request if the user wish to do so.
Moreover transactions-as-querries is still a must have for direct communication between services and over social medias / websites / email. URIs are selectable by the user, while direct transaction request are imposed to the user.
It's a bit similar, except you won't ever need the full message history, since signing requests are removed when they 1) have enough signature weights, 2) have enough rejections that they can't ever reach (1), 3) are cancelled by the creator, or 4) expire by means of a timeout.
Spam could become an issue, not sure how to deal with that yet. I'd prefer something you don't have to pay for, since that opens up a whole new can of worms.
