O que é um contrato inteligente e por que era necessário?
Há muito tempo, após o surgimento do Bitcoin - a primeira máquina de estado replicada - as pessoas começaram a perceber que a funcionalidade incorporada no consenso é muito limitada. Não estou falando de adicionar criptocots à negociação, mas de casos de usuários bastante reais - DNS em que cada domínio pertence a uma chave pública e não a um registrador centralizado, todos os tipos de tokens e derivativos financeiros (porque você deseja possuir ações da mesma maneira que possui bitcoin), trocas onchain (para negociar grandes quantias sem confiar na troca), canais de pagamento (redistribuir rapidamente o compromisso geral entre duas contas sem sobrecarga de uma mensagem de transação em geral) ...
Havia três maneiras de adicionar funções:
1) o mais óbvio é inseri-los no código do próprio blockchain, nativamente.
O Blockchain é essencialmente um site replicado . Quando você não possui funções suficientes no site, o que está fazendo?
Basta adicioná-lo diretamente ao código como um novo modelo ou controlador . Porém, no caso de uma rede descentralizada, não há processo para essa alteração de modelos / controladores - afinal, ela pode ser usada para sua vantagem. Somente uma opção de garfo rígido, onde todos concordam em bate-papos / fóruns.
2) crie outra blockchain com essa funcionalidade.
O mesmo aconteceu com várias "blockchains of one idea" ala namecoin. Logo se percebeu que as pessoas não querem usar a nova rede para uma função, elas também precisam de interoperabilidade e muitas coisas dependem uma da outra (empréstimos, identidades e ativos querem viver no mesmo espaço de endereço)
3) implemente funções usando a máquina virtual interna e os códigos de operação.
Até Satoshi colocou o Script no Bitcoin precisamente por causa do problema de atualização, que permitiu fazer muito, mas não foi suficiente. Portanto, um script estendido foi proposto por ether (agora completo) e você pode fazer qualquer coisa com ele (em teoria).

Portanto, é o código executado pela máquina virtual dentro da blockchain que é chamado contrato inteligente e é necessário para implementar novas funções. Você pode chamá-lo de "patch opcode", mas não está vendendo tão bem :)
O que é uma atualização inteligente?
Em relação aos contratos inteligentes nos últimos dois anos, podemos dizer claramente que eles não atenderam às expectativas. Sim, o boom da ICO não foi possível no bitcoin, mas introduzir um EVM avançado apenas para tokens erc20 foi demais.
Escrever até um pequeno “pedaço” de solidez é extremamente difícil. No nível inferior, você encontrará uma VM bruta que possui muito poucos códigos de operação (por design) e um banco de dados de valores-chave simples. Todas as operações são extremamente caras (custo do gás) e você não pode se virar.
Casos sofisticados de usuários são quase impossíveis. Veja Ryden
github.com/raiden-network/raiden-contracts/tree/master/raiden_contracts/contracts - milhares de linhas de código, na língua estrangeira bruta (solidez), para gerenciar um sistema financeiro complexo. Vimos vários hacks de paridade e DAO com ataques simples. Que tipo de ataque nos espera em uma base de código tão monstruosa?
Não há banco de dados SQL, NoSQL não está presente, o banco de dados gráfico também não está planejado. Iteração de chave, muitos para muitos? ORM? Nada disso existe dentro do contrato. As ferramentas também são muito fracas em relação às linguagens de programação conhecidas.
95% do trabalho de um projeto moderno de solidez é precisamente a luta contra a solidez e não a arquitetura do código. A mesma idéia pode ser implementada em javascript dez vezes mais rápida e mais confiável, simplesmente porque sabemos e podemos escrever javascript e o ecossistema de solidez não foi muito além do ecossistema de foda cerebral.
Em defesa da EVM, ainda vou dizer - a imagem no mundo do bitcoin é ainda mais triste porque a afinação é ainda mais fraca e os códigos de operação são ainda menores . Os desenvolvedores de relâmpagos estão mordendo, mas ainda têm um cacto - a complexidade de um canal de bitcoin bidirecional no Bitcoin é tão louca que manter a base de código é ainda mais difícil, e coisas convenientes como Sprites e lógica complexa dentro do canal de estado são simplesmente impossíveis.
Governança Onchain = Atualizações Inteligentes
Tendo farto da tristeza e da solidez, vamos voltar para 2012 e relembrar a
primeira opção descartada
com a adição de casos de usuário nativamente ao blockchain.
Como muitos notaram, após a implementação do EVM, o próprio EVM não parou de atualizar como deveria (o nível básico nunca muda, todo o novo código está apenas dentro do EVM) - pelo contrário,
ele se bifurca regularmente com a ditadura do ethereum.I.e. os mesmos ovos apenas no perfil. Um grupo de pessoas decide como alterar a camada onchain com as próprias mãos, coloca o código no github e todos os usuários não têm escolha a não ser baixar um novo código. "O garfo rígido está programado para sexta-feira, atualize imediatamente", eles nos dizem.
Dessa forma, a idéia de contratos inteligentes é absolutamente um fracasso -
já temos autoridade que determina como a camada de consenso funciona (conta do ethereum no github), para que serve uma abstração extra e ineficaz se não conseguirmos nos livrar das atualizações da camada principal?
Como não podemos nos livrar das atualizações, vamos pelo menos descobrir como atualizar essa camada principal para nós o mais descentralizada possível.Podemos oferecer patches de software dentro do blockchain, os validadores podem votar neles e os patches vencedores são simplesmente implementados para todos de forma síncrona após algum período. Essa idéia de "governança on-chain" está no ar há algum tempo, mas Tezos foi o primeiro a descrevê-la, se não me engano. O que os tezos perderam de vista é que a governança onchain é um concorrente direto de contratos inteligentes
(é por isso que eu chamo de atualizações inteligentes).Se você possui atualizações inteligentes, você simplesmente não precisa de contratos inteligentes. Qualquer caso de usuário pode ser implementado mais rapidamente, melhor, com qualquer banco de dados de sua escolha (SQL / NoSQL / qualquer que seja), em qualquer linguagem de programação (você executa o código já no nível da máquina e não se limita a nada). Liberdade total, menos os 95% de sobrecarga que você gastou em solidez, e não precisamos esculpir um novo blockchain como solução nº 2.
Existem exatamente dois desvios para atualizações inteligentes
1. Agora, nem todos os casos de usuários serão aprovados pelos validadores, pois eles pensam e votam que tipo de patch será útil para a rede (e cortam backdoors francamente maliciosos). É improvável que coisas como criptomoedas sejam aprovadas pela maioria (uma retenção de 67% ou 95%, configurada dentro da própria rede)
2. Os validadores podem usar essa força para aplicar esses patches que são diretamente benéficos para eles (remover um usuário questionável, permitir obter ativos de três caixas). Para resolver esse problema, há um período de atraso. Após a aprovação do patch, toda a rede tem de 2 a 6 semanas para estudar. Se os usuários comuns não gostarem, as pessoas devem se reunir, fazer uma forquilha e substituir o conjunto de validadores por outros mais adequados (ou jogar fora os piores caracteres).
Parece assustador, mas
já funciona assim - o athereum github pode oferecer absolutamente qualquer coisa difícil e essa é a tarefa dos usuários de redefinir a ditadura se eles não gostarem de algo.
Não vai ficar pior. Simplesmente formalizamos esse processo e fornecemos bifes transparentes para cada desenvolvedor / validador, em vez do governo “sombra” existente com o primeiro canal na forma de um repositório do github.
Sumário
Assim, descobrimos que os contratos inteligentes da EVM são um conceito interessante que acabou sendo uma falha, uma mudança muito pesada na direção errada, quando tudo o que era necessário era implementar um mecanismo transparente para atualizações inteligentes para resolver o problema de novos casos de usuários.
O futuro é para atualizações inteligentes, e quase todas as blockchains atualmente em desenvolvimento as incluem desde o início (tezos, dfinity, polkadot, decred, tendermint, fairlayer, etc.). Mesmo nos próprios contratos inteligentes, eles agora estão tentando ativar o mecanismo de atualização dentro de si mesmos,
percebendo que o conceito de imitação não funciona e, de alguma forma, mais cedo ou mais tarde, será necessário atualizar .
Aqui está uma
wiki mais
detalhada sobre esse tópico (em inglês. Estou surpreso com o fato de Vitalik e Vlad Zamfir tentarem
denegrir atualizações inteligentes , seu concorrente direto tornando a EVM completamente obsoleta.