D4ryl00

What this is

A latency analysis to decide which hardware signer to use for gno validators. We have a Ledger Nano S Plus on hand. We don't have a YubiHSM 2, so its column is filled in from Yubico's published Ed25519 numbers — good enough to make a decision, but flagged as vendor-reported.

To put either number in context, we also need to know how much overhead gnokms itself adds on top of any backend it talks to. We measure that by running gnokms with the gnokey backend (CPU-only, no hardware) and comparing it against an in-process Ed25519 baseline. That way, when we look at the Ledger number, we can separate gnokms cost from USB cost from on-device cost.

All numbers in ms. Same host throughout: Linux 7.0.3-arch1-2, Ryzen 7 7800X3D, USB Full-Speed HID. Ledger Nano S Plus firmware 1.6.0 running the gnoverse/tm-ledger-validator Ed25519-only validator app (the Tende

D4ryl00

Hardware signing latency for gnoland validators

Validator signing is not only a key-management problem. It is also a latency problem.

During one consensus round, a validator may sign up to three message types:

• proposal, only if it is the proposer
• prevote
• precommit

D4ryl00

package yourproject

import (
    "fmt"
    "runtime"
    "strings"
)

func getStackFrameInfo(frame int) (string, bool) {
    pc, file, line, ok := runtime.Caller(frame)

D4ryl00

module pubsub-event

go 1.19

require (
	github.com/libp2p/go-libp2p v0.23.2
	github.com/libp2p/go-libp2p-pubsub v0.8.1
)

require (