Loading

Module 1: Bitcoin Blockchain

Nota de Estudos
Study Reminders
Support
Text Version

Blockchain Growth Dynamics

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

Agora, olhemos para a dinâmica de crescimento. Então eu tenho falado sobre isso por um tempo, mas deixe-nos  
olhe para ele mais formalmente. Em um determinado momento, todos os nós que estão mantendo uma cópia ou réplica  
do blockchain terá uma sequência de blocos sobre os quais o consenso se deu. E  
houve um acordo de que estes são os blocos que foram tornados permanentes no  
blockchain. Assim, cada nó terá algum conjunto de nós que já estão passando pelo  
consenso.  
E então cada nó terá um conjunto de transações que não fizeram parte de nenhum desses blocos.  
E eles têm que decidir qual dessas transações eles vão querer colocar em um bloco. Então, eles podem  
decidir que eu colocarei apenas isso porque os blocos têm também um tamanho fixo. Então, eles podem não ser capazes  
para colocar todas as transações que ainda estão pendentes. Então, essas são as transações pendentes, você  
têm que selecionar a partir deles.  
E então colocado em um novo bloco e cada nó que faz parte do processo está fazendo a mesma coisa.  
Eles têm uma sequência de blocos e que já estão consentidos e então eles têm um conjunto inteiro  
de transações pendentes.  
(Consulte O Tempo De Deslizamento: 15 :58)  
Quando você tem essa transição pendente deixe-nos dizer neste exemplo, há 3 mineiros diferentes.  
E eles estão usando, é claro, a mineração solicita uma solução de quebra-cabeça de hash, então eles têm altíssimas  
poder de computação, e assim por diante. Então esse cara decide que esse conjunto de transações vai ser no próximo  
bloco. Esse cara decide que esses são o conjunto de transações no próximo bloco. E esse cara  
decide que estes são o conjunto de transações no próximo bloco.  
E isso pode haver muitas razões pelas quais esses 3 são diferentes. Uma possibilidade é que o  
transação como sua transmissão, eles levam algum tempo para chegar a todas as partes da rede. Assim pelo  
vez que este cara coletou algumas transações, algumas das transações nem chegaram a isso  
nó. Portanto, portanto, este nódulo, ele nem sequer sabe a existência de uma transação. Este nó  
também pode decidir que eu tenho esse muito espaço, tantos kilobytes em um bloco.  
Eu tenho muitas transações. Selecionarei aleatoriamente alguns deles. E esse cara também tem o  
mesma questão para que ele possa ter ouvido falar dessas transações ou obtido uma cópia da transação que esta  
cara não conseguiu. Mas pelo menos ele conseguiu isso para que ele coloque isso em mas por outro lado para o outro  
transações, ele escolheu aleatoriamente a partir das transações pendentes que caberão em seu  
bloco. Pode haver outras razões, falaremos sobre que pode haver uma razão de incentivo  
por que eles escolhem certas transações, que podem não ser totalmente aleatórias.  
Mas, em qualquer caso, todos esses blocos parecerão diferentes. Talvez não talvez alguns deles sejam  
exatamente o mesmo por virtude da probabilidade, mas não há eles não estão falando uns com os outros  
decidindo quais transações vão para o próximo bloco. Assim, todo mundo vai propor um bloco que pode  
ser um pouco diferente. Agora, quando você propõe um bloco, eles e se difundem que este é o meu  
próximo bloco proposto, este bloco deve fazer parte do blockchain.  
Se todo mundo fizer isso, haverá uma enorme quantidade de dados indo em e então quem quer que seja  
nó que está mantendo uma cópia do do blockchain será confundido porque você obterá  
milhares de propostas de blocos diferentes e ele não saberia qual delas tomar so, tem que  
seja algum tipo de mecanismo de consenso através do qual o próximo bloco tem que ser escolhido. Então, deixe-nos  
veja o que acontece.  
(Consulte O Tempo De Deslizamento: 18 :23)  
Agora, como eu disse antes, que nós pode haver uma falha de travamento em alguns nós enquanto eles são  
participando do processo de consenso ou alguns nós podem se comportar maliciosamente em cima disso, o  
A rede tem imperfeições. Assim, nem todos os pares de nós estão diretamente conectados é claro, portanto eles  
há longos caminhos entre eles ou, às vezes, há uma segmentação na rede porque  
de várias razões. Assim, nem todas as transações estão alcançando ou todo o bloco transemissora atingindo todos  
nós muito instantaneamente, eles podem levar tempo.  
Então, há latência e, em seguida, a rede pode ter falhas por causa disso talvez o roteamento esteja levando  
lugar e assim, em cima disso, pode-se dizer que bem, se todo mundo trouxesse bloqueio personalizado, eu vou  
veja o selo de hora neles. E então eu vou decidir qual deles tem o timestamp mais baixo e eu  
irá levá-lo mas que isso também é problemático porque a noção de tempo nos vários nós que  
estão geograficamente distribuídos não são exclusivos.  
Então, e então os relógios têm que não são sincronizados, não há nenhum relógio global mantido para fazer  
isto, se houvesse um relógio global, ou seja, cada computador tem o mesmo relógio, então eles poderiam ter  
realmente o fez muito mais facilmente dizendo que o menor timestamp one será tirado. Mas  
agora os timestamps não serão dignos de confiança porque nenhum dos nós está em fusos horários diferentes  
primeiro de tudo, mas mesmo que você se ajuste para o fuso horário.  
Todo mundo ’ s deixe-nos dizer, expressa seu tempo como um tempo GMT ou UNIX mesmo então há um  
problema porque relógios alguns relógios são mais lentos por causa de vários drifts e defasados e outros  
relógios podem ser mais rápidos. Então, a menos que você mantenha um tempo global usando relógio GPS ou algum outro  
protocolo para sincronização de tempo, isso não funcionará. Então, o time stamp não é uma solução para isso  
problema.  
(Consulte O Tempo De Deslizamento: 20 :26)  
Mas enquanto nós vamos e olhamos para a literatura sobre consenso, descobrimos que esse problema de consenso  
também é chamado de problema de generais bizantinos. Mais tarde no curso vamos realmente discutir isso em  
muito mais detalhes. Mas a ideia aqui é que se você tem o site inimigo alvo e há 2  
Garrison's que são desconectados uns dos outros, exceto que eles podem enviar mensagens para cada outro  
e eles sabem que não podem ganhar isso, o atacando isso.  
E quando isto a menos que ambos realmente atacam simultaneamente a partir destes 2 lados. Se um de  
eles ataca e depois o outro não, então quem ataca será morto completamente. Então então  
temos um problema de consenso de que temos 2 Garrison's com 2 generais. E eles têm que decidir  
se eles vão atacar ou se eles não vão atacar. E ambos os  
ter que não atacar ou recuar ou ambos tem que decidir atacar.  
Então, é isso que se chama de problema de generais bizantinos. Agora, o problema aqui é que se todo o  
generais são honestos, e os mensageiros que foram enviados e para trás e para trás são honestos, então este  
problema não é um grande negócio. Então, um general decide e depois envia para esse cara reconhece e  
então ambos os dois vão atacar ou ambos vão recuar. O problema é que se você assumir isso  
um dos gerais poderia ser mal-intencionado ou os mensageiros poderiam estar realmente mudando o  
mensagens, então isso pode realmente falhar.  
Então, nesse caso, eles podem, esse cara pode pensar que o consenso é atacar e esse cara é  
realmente achar que o consenso é fazer retiro e, portanto, atacar sozinho e depois ficar dizimado  
certo. Por isso, portanto, é preciso ter um consenso de que tal que os generais honestos, opinião  
deve, eventualmente, prevalecer, quando a coisa toda se liquida. Portanto, portanto, este problema tem sido um  
modelo para este problema de consenso como problema de tolerância a falhas bizantinas ou chamado de BFT.  
Então, veremos muito essa discussão e a BFT depois. Então, mas resultado antecipado a partir de 1979, eu acredito por  
isto também é chamado de resultado FLP. O FLP basicamente diz que se todos os nós executam um   determinístico  
algoritmo, então o consenso é impossível mesmo quando um único nó pode travar. Então, isso é um   muito ruim  
notícias. Então, o que estamos dizendo é que resolver generais bizantinos estabelecendo problema de consenso, ou  
BFT, o consenso tolerante a falhas bizantinas é impossível mesmo quando um único nó pode ser defeituoso. Então,  
que é um no nosso caso, não podemos até mesmo garantir nó único pode ser muitos nós que são  
indo ser malicioso ou defeituoso então então o que você faz.  
(Consulte O Tempo De Deslizamento: 23 :57)  
Mas há algoritmos práticos como o Paxos. Por isso, também falaremos mais tarde sobre isso. Mas Paxos  
é um protocolo de consenso tolerante a falhas bizantinas. E nós da maneira que Paxos trabalha é que bem ela  
nunca produz um resultado inconsistente que são os alguns nós estão dizendo sim e alguns nós são  
dizendo que não, mas às vezes pode ficar preso e nunca terminar. Então, lembre-se que dissemos que um  
O protocolo de problemas de consenso deve sempre finalizar.  
E eles devem sempre dar um resultado e todos os nós bons são nós não maliciosos devem  
chegam ao mesmo resultado. E esse resultado deve ser proposto por um dos bons nós. De modo que  
era a exigência de um protocolo de consenso. Agora, Paxos faz todo o resto, menos que isso pode  
não finalizar às vezes. Então você pode ficar preso mas há outras maneiras de resolver esse problema.  
(Consulte O Tempo De Deslizamento: 25 :02)  
Então, uma coisa que é interessante sobre resultados impossíveis de resultados ou resultados de dureza NP ou qualquer tipo de  
complexidade menor resultado limite é que é sempre o pior cenário de caso por exemplo, aqueles de  
você sabe que a dureza NP so satisfiability sat é CNF SAT é conhecida como NP hard NP completo  
problema. E acontece que muitas instâncias de sat não são difíceis de resolver, mas há muito específicas  
tipos de problemas tristes que requerem a você saber, tempo exponencial.  
Então, portanto, o que, o que podemos realmente dizer é que o resultado impossibilidade depende da própria  
Caso de canto ou pior caso também, o resultado da impossibilidade aqui em caso deste resultado da FLP é mais  
sobre suas suposições em como o modelo deve funcionar e qual é o comportamento deles, para  
exemplo, eles supõem que o modelo requer que cada nó faça uma atividade determinística. Assim  
houve algoritmos tolerantes a falhas bizantinas, que trabalham com quase probabilidade um,  
que são algoritmos probabilísticos ou randomizados.  
Esses modelos foram desenvolvidos para estudar sistemas como bancos de dados distribuídos. E agora, o que nós  
vai ver como a gente volta é que esse resultado FLP não, você sabe, nos impede de realmente ficar  
consensualmente probabilisticamente no blockchain Assim, veremos que o probabilisticamente o  
O consenso funciona em blockchain.