Probabilidade para geeks

por Frances Coppola

A rede relâmpago (Lightning) está sendo apontada como a solução para problemas de escala com o Bitcoin. Se muitas transações podem ser retiradas da cadeia principal, o pensamento vai, em seguida, no sentido de que Bitcoin ainda pode conquistar o mundo, apesar de seus problemas de desempenho consideráveis. Os entusiastas do relâmpago dizem que quando totalmente aprovada, a rede será capaz de processar milhões de transações na velocidade da luz, sem comprometer a descentralização, a segurança ou transparência. 

Mas há vozes discordantes. Por exemplo, neste post , Jonald Fyookball contesta as reivindicações dos entusiastas do relâmpago sobre os motivos que a matemática não se comparam. Previsivelmente, os geeks-raios têm lutado para trás: o pseudônimo "Murch", um engenheiro de software na bolsa criptomoeda Bitgo, descreve a análise de Fyookball como "risível". 

Fyookball descreve a rede relâmpago assim: 

Para enviar ou receber bitcoins, você precisa de um canal de pagamento com o usuário específico ou uma série encadeada de canais de pagamento (a “rota”).

É inútil criar um canal de pagamento para o único propósito de enviar uma transação de cadeia off, uma vez que exige uma transação on-cadeia para abrir o canal (e outra para fechar). Assim como você pode simplesmente enviar uma transação corrente on-vez; você não precisa o LN.

A ideia é que você deveria ser capaz de direcionar seu pagamento para qualquer destino através de uma série de conexões. Do ponto de vista de um usuário, o caminho potencial para ninguém se parece com uma estrutura de árvore:

Murch salta sobre isso, dizendo que não é verdade: 

Quando um participante LN procura por uma rota, ele está, obviamente, só interessado em capacidade de pagamento dirigido. Este aspecto está corretamente representado na árvore. No entanto, os nós ao longo do percurso estão interligados. Enquanto isso poderia até mesmo permitir ciclos de ocorrer, os ciclos não são possíveis na construção da rota, como seria permitir que os participantes envolvidos várias vezes para cortar o ciclo quando aprender o segredo para o primeiro tempo. O gráfico resultante é o que chamamos um DAG ou gráfico acíclico dirigido:

Então, quem está certo? O relâmpago é uma estrutura de árvore, ou algo mais complexo? 

Para explicar, vamos olhar para a forma como raios possibilitam a tomada de decisão. Precisamos de todo um elenco de atores, não apenas o famoso Carol e Bob. Relâmpago é suposto ser usado para pequenas transações, então vamos imaginar que Alice quer comprar um café no Starbucks. Ela não tem um canal aberto com relâmpago Starbucks (poderíamos chamá-lo de uma "conta"), então ela pede a sua amiga Carol para pagar Starbucks para ela, e ela irá reembolsar Carol quando o pagamento for feito. Carol não tem um canal aberto ou, então ela pede Bob pagar Starbucks. Bob tem um canal aberto com a Starbucks, então ele faz o pagamento e é reembolsado por Carol, que pode então reclamá-la de pagamento de Alice. Isto se parece com uma estrutura de árvore, não é? 

Não. Cada um dos actores tem mais do que uma relação. Alice poderia ter pedido a Tim ou a Jim para fazer o pagamento por ela. Por que ela escolher Carol? Bem, pode haver toda série de razões. Talvez ela erroneamente pensou que Carol tinha um canal Starbucks aberto. Talvez Tim estava longe de férias e ela não foi capaz de entrar em contato com ele. Talvez Alice simplesmente emitiu uma mensagem de broadcast para todos os seus amigos e Carol foi o primeiro a responder. Talvez Carol foi simplesmente a primeira pessoa a entrar na mente de Alice. Há todos os tipos de razões pelas quais as pessoas podem escolher um participante particular. 

Carol, também, tem mais de um relacionamento. Por que ela escolher Bob? Não sabemos. E importante, Alice não sabe. Quando Alice pede Carol para pagar Starbucks, ela não sabe que caminho pagamento Carol vai escolher. Carol não tem que enviar o pagamento diretamente. Na verdade, se ela não tem um canal Starbucks aberta, ela não pode. Então, ela envia-lo via Bob. Mas ela poderia ter escolhido Tim ou Jim vez. Sim, o mesmo Tim e Jim que Alice também sabe. E se Bob sabe eles também, então ele pode encaminhar o pagamento através de Tim ou Jim em vez de pagar Starbucks diretamente. A estrutura não é, portanto, apenas uma estrutura de árvore simples. 

Mas o mais importante, nenhum dos participantes sabe a rota com antecedência. Cada participante tem um número de escolhas, e nenhum participante sabe o que as escolhas dos outros participantes farão. A rota final não está, portanto, determinado até Starbucks recebe o seu dinheiro e a cascata de pagamento de volta para Alice começa. E porque ninguém sabe o que ninguém vai fazer, a rota final é determinada aleatoriamente. 

Murch contesta isso, então deixe-me explicar. Se assumirmos que todos os participantes são iguais (o que é necessário para a descentralização total), então os mais potenciais participantes houver, maior o número de rotas potenciais, e menor a probabilidade de que uma determinada rota será aquele final. Quando há apenas um número muito pequeno de participantes potenciais, em seguida, as probabilidades podem ser calculadas. Mas quando a rede se expande para milhares ou milhões, como entusiastas relâmpago pretende, então o número de rotas potenciais aumenta exponencialmente, e a probabilidade de qualquer uma rota a ser selecionado se aproxima de zero. Obviamente, uma rota será selecionado: mas a seleção é efetivamente aleatória. 

O argumento de Murch é que todos saibam os seus amigos, por isso a escolha da via não seria aleatória. Receio que esta é a nossa velha amiga, a falácia da composição, também conhecido como "a generalização do particular". Eu sei que meus amigos e eu possa conhecer alguns de seus amigos, mas eu não sei amigos, muito menos seus amigos de seus amigos amigos dos amigos. Uma vez que somos mais do que cerca de um ou dois passos retirados do círculo do originador de amigos, o autor simplesmente não sabe o suficiente sobre a rede para ser capaz de prever que direção a rota de pagamento vai demorar. Nem qualquer outro participante. Os mais potenciais participantes existem, e mais escolhas cada participante tem, menos conhecimento ninguém terá sobre o que está realmente acontecendo. 

As rotas de pagamento podem se tornar muito longas e muito complexas, sem ninguém saber. Elas poderiam até mesmo se tornar recursivas. Porque este é um DAG não uma estrutura de árvore, é inteiramente possível que a mesma pessoa possa ser solicitada a fazer um pagamento mais de uma vez na mesma cadeia, por dois participantes diferentes. Murch diz que isso não é possível, mas a menos que haja algum tipo de gordura Controlador de impedir a participação duplicado em cadeias de pagamento, ele está errado. Qualquer um pode escolher seus participantes, e as pessoas só vêem seus próprios quintais, por isso é absolutamente possível para um pagamento a ser enviado duas vezes para o mesmo participante, e ninguém saberia. 

Mas por que pode um pagamento simples de Starbucks tornou tão complexo? Bem, isso me leva à segunda área de disputa entre Fyookball e Murch. Fyookball descreve pagamentos relâmpago como "empréstimos". Murch diz que eles são nada do tipo: eles são simplesmente uma balança comercial. Quem está certo? 

Desta vez, Fyookball é certo. Lightning é um sistema "pull". Cada participante faz um pagamento, em seguida, "puxa" o reembolso do participante anterior. Assim, cada participante tem de ter "fundos próprios" suficientes em seu canal para fazer o pagamento. Se não o fizerem, eles não podem participar na rota, e seu predecessor deve encontrar um participante diferente. Usando "fundos próprios" para fazer um pagamento em nome de outra pessoa se enquadra na definição normal de "empréstimos". Pode ser resolvido dentro de milissegundos (ou não, como veremos), mas isso não muda o que é. 

Note-se também que ninguém é pago até Starbucks fazer. Carol não pode reclamá-la de pagamento de Alice até Bob afirma que seu pagamento a partir dela, e Bob não pode reclamar o seu pagamento de Carol até Starbucks afirma que seu pagamento dele. O pagamento final na rota desencadeia uma cascata de reivindicações. Quando há uma grande quantidade de saltos na rota, portanto, reembolso para os primeiros participantes poderia ser significativamente atrasado. 

Os atrasos de reembolso poderiam degradar seriamente o desempenho da rede. Quando um participante se compromete a um pagamento, os "fundos próprios" do canal devem estar disponíveis para esse pagamento. Mas quaisquer fundos já comprometidos com outro pagamento que ainda não tenha resolvido não estão disponíveis. Podemos pensar nisso como a venda de sua casa: se você já tiver trocado contratos com alguém, mas a venda não foi concluída porque há um bloqueio mais acima na cadeia, você não pode vender a sua casa para outra pessoa. Se houver fundos insuficientes desonerados no canal, o participante não pode cometer ao pagamento, e o canal se torna "sem resposta". Quando o tráfego de rede é pesado, então, se todos os participantes são pequenos usuários com recursos limitados, é possível que todos os potenciais rotas de pagamento disponíveis de cada participante podia ficar sem resposta, resultando em pagamentos não completem. Esse é o impasse. 

E se você acha que isso não poderia acontecer, você precisa jogar o jogo de Londres . Neste, os jogadores montar sistema de metro de Londres para chegar a vários destinos turísticos aleatoriamente-determinados. Você começa em uma grande estação de trem de Londres, e você usar o mapa do tubo de trabalhar para fora como para chegar ao seu destino. Note que este já é significativamente menos difícil do que o sistema de Raios, porque pelo menos você pode ver todo o mapa e elaborar uma rota viável. Em relâmpago, você não pode ver mais do que um par de paragens de metro além do seu ponto de partida. 

Mas suas rotas escolhas são imediatamente comprometida por duas coisas: as decisões de outros jogadores sobre os quais paradas tubo deve ser fechado (ficar sem resposta, na linguagem relâmpago), e os cartões de perigo que significa que você pode ser desviado aleatoriamente em outro lugar (este se aproxima de perder o controle de sua rota, como você faz em Lightning) . Vamos supor que você está tentando obter a partir de Victoria para Tower Hill, e alguém decide fechar Embankment. Eu coloquei um mapa de metrô de Londres na cabeça deste post para que você possa divertir-se trabalhando fora que efeito que tem sobre o que era uma rota curta, simples bastante. Ou vamos supor que você estava tentando obter a partir de Liverpool Street para o parque do regente, mas você se desviado por um cartão de Hazard e acabam no templo, novamente com Embankment fechado. Não é difícil ver que as rotas disponíveis rapidamente tornar-se longo, complexo e congestionado - e isto é com apenas uma paragem de metro fechado. À medida que mais paragens de metro estão fechados, é realmente possível para alguns participantes para ser completamente incapaz de se mover: por exemplo, se você estiver no St. James Park e alguém fecha ambos Victoria and Westminster, você não está indo a lugar algum. 

O engarrafamento é, claro, a diversão do jogo de Londres. Mas quando ocorre em um sistema de pagamentos (ou no metrô, na realidade, é claro) não é nada divertido. 

Agora, é claro que o metrô de Londres não é um sistema totalmente descentralizado. Todas as paradas de tubo não são iguais. Tirando Oxford Circus tem um efeito muito mais perturbador sobre o tráfego de rede do que tomar Swiss Cottage. Relâmpago pelo menos tenta nivelar o campo de jogo, mas fá-lo ao preço de impasse inevitável. A combinação de baixos níveis de fundos em canais de pagamento com os atrasos nos pagamentos devido a longas cadeias é mortal. 

A Lightning tem um segundo problema, também. Porque os jogadores do jogo de Londres podem ver todo o mapa, eles gastam muito do seu tempo trabalhando fora rotas alternativas. Mas os usuários do relâmpago não podem ver todo o mapa. Tudo o que podemos fazer é tentar diferentes canais de pagamento. A sua situação é bastante semelhante a um usuário Tube, sabendo que Westminster é bloqueado, decidir ir via Oxford Circus em vez disso, apenas para descobrir no Green Park, que Oxford Circus está bloqueado também. O fato de que ninguém sabe tanto o passado ou o futuro de uma rota de pagamento cria a possibilidade real de que alguns pagamentos não pode nunca chegar ao seu destino em tudo, mas vagar a rede para sempre como a Flying Dutchman. 

Suponha que o pagamento de Alice não consegue resolver. Ele pula de participante para participante, mas ninguém nunca envia para Starbucks. Como isso se olhar para os participantes? Bem, Carol, Bob, Tim, Jim, Antigo Uncle Tom Cobbleigh e todos perdem dinheiro, porque eles fazem os pagamentos para o qual eles nunca são reembolsados. Nenhum deles sabe por que o pagamento não conseguir resolver, porque todos eles podem ver é o seu próprio quintal. Eles não percebem que o problema é que ninguém tem um canal com Starbucks, ou se eles têm um, eles não podem ou não querem usá-lo. Então eles murmurar sobre fundos sendo "roubados". E Alice pode enfrentar um processo de Starbucks por não pagar para o café. 

Porque esta é uma rede, não há absolutamente nada que qualquer um deles pode fazer para parar o vaguear de pagamento, exceto através da abertura de um canal com Starbucks - e por que eles fazem isso para um pagamento único? Individualmente, as suas decisões não enviam o pagamento as Starbucks são, sem dúvida inteiramente racionais. Mas coletivamente, seu comportamento resulta em uma falha de pagamento. Isto é o que Fyookball quer dizer quando refere-se à possibilidade de que pode não haver um caminho em tudo. 

Mas é a solução da Fyookball melhor? Bem, tendo dedicar canais de pagamento com reservas muito maiores que permaneçam online o tempo todo facilitaria o problema de liquidez do relâmpago, e se a liquidez for mais abundante pode haver menos probabilidade de que os pagamentos iriam aproveitar para cima ou para "passear". As pessoas simplesmente enviam o seu pagamento a um hub de liquidez, o que manteria um canal permanentemente aberto com Starbucks. Mas isso dificilmente poderia ser chamado de "descentralizada". O cubo de liquidez, inevitavelmente, seria um alvo para os ladrões e hackers. E se ele desceu, a rede pode ter um ataque do coração, assim como fechar Oxford Circus traz toda a rede de metrô de Londres a um impasse (acredite, ele faz). 

Claro, Lightning é um sistema financeiro, não uma rede de transportes. Então, talvez devêssemos chamar um tal canal de pagamento centralizado por um nome diferente. "Lehman Brothers", por exemplo. O que acha disso?