Re: Implementing Decentralized RPKI with Blockchain Technology

[Matt Corallo <nanog () as397444 net>]

On 11/13/24 10:45 PM, Seth David Schoen wrote:
> Matt Corallo writes:
>
> > I see where you're going - blockchains are an audit log (eg Certificate
> > Transparency) and cryptocurrencies generally use something expensive to
> > perform anti-sybil to gate appending to the audit log, but allowing the
> > largest ISPs to randomly assign or re-assign resources doesn't solve the
> > problem, it only makes it worse (and we can't do the thing cryptocurrencies
> > do where resource holders have keys which are required to move the
> > resources, because its legitimate for a RIR to reclaim resources for
> > non-payment).
> >
> > Having a cryptographic audit log of RPKI changes (published by the RIRs,
> > presumably) isn't the worst idea in the world, but it doesn't really buy us
> > a lot so its just kinda added complexity.
>
> There are some tools out there either directly using or inspired by
> Certificate Transparency that facilitate transparency logging of other
> kinds of events.  It might be interesting to put RPKI events into one
> of those.
>
> The big difference between blockchains and systems like CT is that the
> latter do have single points of failure (an operator can shut down the
> log completely, or break it in other ways), or at least relatively
> small numbers of organizations that together have this power.  But
> participants in the system who cheat will generally get caught doing so
> (that is, they'll leave records showing that they cheated).
>
> A blockchain doesn't have the single point of failure, because new parties
> can always come in and start mining on it even if previous miners cheat
> or stop.  (Like in real life, the government of China apparently somewhat
> abruptly told the huge community of mining companies there to stop
> mining Bitcoin, and miners elsewhere seamlessly picked up the slack.)
> But a blockchain may have extremely high overhead in order to achieve
> that property, whereas a system like CT doesn't.
>
> We might say that a blockchain is tamper-proof (if its economic
> assumptions hold!) while CT is more tamper-evident.  CT logs can and
> do fail

Eh, semantics. Many people (including myself!) refer to CT as a blockchain. What you're referring 
to, where there are many entities collaboratively advancing a blockchain, I'd call a cryptocurrency :).

In any case, my point in the prior email was that a non-decentralized blockchain is probably the 
only relevant design in this space, as there is a natural operator already, so there's no need for 
any of the (attempts at) decentralized approaches.

Matt