Would Jepsen be relevant to test a multisignature protocol?

11 views
Skip to first unread message

Arnaud Bailly

unread,
Mar 3, 2022, 2:02:49 PM3/3/22
to Jepsen Talk
Hello Jepsen team,
I have used Jepsen a bit in the past, and even tried to contribute some minor stuff to it, and I ♡ both the idea, the implementation, the philosophy and the ethics behind the work you are doing, but never had a chance to apply it for real in my professional. 
But now comes an opportunity where I think Jepsen could be a good fit, but before embarking into flexing my Clojure muscles and implement a test, I would like to have your expert insight on whether or not this makes.
I want to implement a testing framework for nodes implementing a protocol named Mithril that provides so-called Stake-based Threshold Multisignature. The gist of it is the following:
- there is a network comprised of nodes where each node has a share of some "stake" 
- periodically the nodes are required to sign messages, which they do using some form of a "lottery" based on VRF and each node's stake: A node as more chance
- the individual signatures of nodes can be aggregated to form a certificate whose validity is predicated on some fraction of the nodes having provided a valid signature,
- each certificate's validity depends on the current stake distribution, which can change from time to time and is part of the data that nodes sign (eg. nodes sign the message and the current stake distribution).
So the idea would be to use Jepsen to drive a cluster of such nodes, inject faults and signing/certificates reading requests, and verify the nodes are behaving correctly.

Does this make sense? Verifying the validity of certificates seems to me to fit within the general framework of checking (strong) consensus in a distributed setting but maybe this is a far stretch?

Thanks for the great work and for any answer you can provide,

Arnaud Bailly

Kyle Kingsbury

unread,
Mar 3, 2022, 2:04:55 PM3/3/22
to ta...@jepsen.io
On Thu, 2022-03-03 at 11:02 -0800, 'Arnaud Bailly' via Jepsen Talk
wrote:
> Does this make sense? Verifying the validity of certificates seems to
> me to fit within the general framework of checking (strong) consensus
> in a distributed setting but maybe this is a far stretch?

Hi Arnaud, and thanks for the kind words. I think that yes, this is a
good fit for Jepsen! You'll need to write a checker that understands
what certificates are and how to verify them, of course, and generators
for signing/reading certificates, but I think the rest should be
relatively straightforward. :-)

--Kyle

Arnaud Bailly

unread,
Mar 3, 2022, 2:08:15 PM3/3/22
to ta...@jepsen.io
On Thu, Mar 3, 2022 at 8:04 PM Kyle Kingsbury <ap...@jepsen.io> wrote:

Hi Arnaud, and thanks for the kind words. I think that yes, this is a
good fit for Jepsen! You'll need to write a checker that understands
what certificates are and how to verify them, of course, and generators
for signing/reading certificates, but I think the rest should be
relatively straightforward. :-)

Wow, that was fast! 

Thanks for the reassurance. Rather than reinventing the wheel, I think it makes sense to invest in existing battle tested tools like Jepsen.
I will start exploring that avenue by refreshing my memories of how Jepsen works :)

Regards,
Arnaud

Arnaud Bailly

unread,
Mar 4, 2022, 2:55:13 AM3/4/22
to ta...@jepsen.io
Just found this digging into the logs of jepsen :-D

% git log --author abailly
commit 10b343cefdad7071e9d5c13a1f42b28ad3882ead
Author: Arnaud Bailly <aba...@foldlabs.com>
Date:   Thu Jul 24 22:25:13 2014 +0200

    added missing tests file

commit 95079bf4c0bfb6c4ec9fc68230372771119b2da4
Author: Arnaud Bailly <aba...@foldlabs.com>
Date:   Thu Jul 3 17:10:18 2014 +0200

    move noop-test and basic db and cas-client to src/ tree

    these are used by tests. By moving them to src/ we ensure they are part of packaged jepsen
    artifact which means people can write jepsen tests in their own projects and depend on a
    single artifact.

commit b0fbdd7f606cecc04d58e0848c6905e9f82c1c89
Author: Arnaud Bailly <aba...@foldlabs.com>
Date:   Tue May 20 00:22:21 2014 +0200

    upgraded to elastisch 2.0-rc1 API

commit a1eafea27594ff0808d3b47bf0d38f17ce8cd5af
Author: Arnaud Bailly <aba...@foldlabs.com>
Date:   Wed May 14 12:01:32 2014 +0200

    isolate system-specific code into profiles

commit db61a4fd79efaf1d9528a72b22590090f4b3f218
Author: Arnaud Bailly <aba...@foldlabs.com>
Date:   Tue May 13 18:07:48 2014 +0200

    cleanup dependencies and make it compile (test do not compile though...)


Reply all
Reply to author
Forward
0 new messages