Neste post, publicamos as respostas de Sergio Lerner, cientista chefe da RSK e RIF, na sessão AMA de abril de 2019.

Que projetos de caso de uso real estão em desenvolvimento? Você tem exemplos?

Houve uma aceleração de desenvolvedores que optaram por construir sua solução em cima da RSK. Algumas das soluções/implementações já disponíveis na plataforma RSK são Circle of Angels, Bitgive e Blockchain for Humanity (todas iniciativas filantrópicas); dexFreight, que é uma plataforma logística; Watafan, um dapp para fãs; Tokkenit, que é um aplicativo de fidelidade; e Insuretech, uma solução de proteção de seguro. Também temos a Chronologic para programação descentralizada e novas soluções em desenvolvimento, como a Investoland (uma plataforma global e descentralizada de investimentos), a Money On Chain (uma solução para gerenciar a volatilidade dos ativos de criptografia) e Gasnor, do Grupo Sabra, que fornece uma solução para distribuição de gás. Esses são apenas alguns exemplos.

 

Houve uma conversa no Twitter um tempo atrás sobre a possível implementação do Chainlink como uma resposta aos seus Oracles: http://bit.ly/2H7z8uV. Você pode nos atualizar sobre o progresso dessa implementação (se houver alguma novidade)?

O serviço RIF Data Gateways é projetado para suportar diferentes serviços Oracle. Uma implementação proposta é um serviço Oracle descentralizado, baseado no nó de rede oracle Chainlink Core. Estamos avaliando um provedor de serviços baseado no Chainlink para os gateways de dados do RIF. Esse provedor usa um nó Chainlink, de modo que os operadores de nós podem aceitar tanto os tokens LINK quanto RIF tokens para seus serviços Oracle. Os operadores de nó poderiam, então, atender a solicitações provenientes da rede RSK (pagas em RIF Tokens) e as solicitações originais provenientes da rede Ethereum (pagas em tokens LINK)

 

Vocês estão pensando em implementar alguma solução relacionada a identidades descentralizadas como um serviço no RIF? Talvez algum tipo de camada de gerenciamento de identidades descentralizadas, PKI descentralizada, rede de confiança descentralizada ou Identidades Soberanas. Vocês estão desenvolvendo algo nesse sentido, ou estão em contato com outras organizações ou fundações que trabalham nessa área específica? Eu acho que poderia ser algo de grande valor e uma grande vantagem sobre outras plataformas de contrato inteligente.

Sim. O RIF Identity é um dos componentes mais importantes das RIF Libraries. Ela fornece os elementos básicos para ancorar identidades na rede RSK e, posteriormente, assinar e trocar atestados de eventos que mais tarde podem ser usados para construir modelos de reputação. Estamos em conversas com os principais especialistas dessa área (Sovrin, uPort e outros) para definir um padrão comum.

Temos também uma relação de trabalho com a Microsoft, que faz parte do projeto ID2020, e estabelecemos uma parceria com a ONG Bitcoin Argentina, o Banco Interamericano de Desenvolvimento e a Accenture (outro membro do ID2020) para criar e implementar o primeiro ecossistema financeiro inclusivo, construído em torno da identidade da reputação, nas favelas de Buenos Aires.

 

Você poderia explicar algo sobre os serviços de armazenamento no RIF?  Seria algo como o IPFS? Eles usarão IPFS ou alguma outra solução similar já em funcionamento?

A IOV Labs está trabalhando para ter uma API unificada para armazenar e recuperar arquivos e suportar várias redes de armazenamento. Esse é o protocolo de armazenamento de dados do RIF. Para um primeiro provedor de rede, analisamos as soluções existentes (Swarm, IPFS, Storj, Sia, etc.) e decidimos que seria baseado no Swarm. A maioria desses protocolos implementa uma variação do seguinte: um arquivo carregado é dividido em partes e distribuído na rede. Quando o arquivo é solicitado, todas as partes são recuperadas e montadas. Cada nó que participa dessa rede está acompanhando os dados armazenados/fornecidos para fins de pagamento. A inovação que estamos trazendo neste momento é simplificar o modelo de incentivo e os mecanismos de prova. É claro que o armazenamento de dados do RIF se integrará a outros serviços RIF, como o RNS (para recuperar arquivos nomeados e permitir a mutabilidade) ou RIF Payments para fins de incentivo. Além disso, no futuro, promoveremos a integração de todas as redes de armazenamento bem-sucedidas nas mesmas API e UI do RIF Storage, para que o usuário possa alternar entre back-ends da rede de armazenamento de forma simples, apenas selecionando o provedor de uma lista ou até mesmo armazenando um único arquivo em múltiplas redes simultaneamente.

 

O que mudou após a atualização de rede Orchid v0.6.0? Há outras atualizações planejadas no momento?

A RSK Labs lança periodicamente novas versões do cliente da plataforma RSK, adicionando novos recursos, correções de bugs e atualizações de segurança. O Orchid versão 0.6.0 foi a última atualização de rede, contendo principalmente alterações no código de operação STATICCALL para ativar o suporte para contratos de Solidity 0.5.x. Lançamos duas novas versões após a 0.6.0, ambas contendo pequenas correções de erros, melhorias de desempenho e reduções nos requisitos de armazenamento de blockchain. O Orchid 0.6.2 também tem grandes refatoradores de base de código, em preparação para a próxima atualização de rede da RSK versão 1.0.0. A versão 1.0.0 está em sua fase final de testes, portanto o lançamento está bem próximo. Essa atualização de rede inclui o Unitrie (novo projeto para a estrutura interna de dados que mantém o estado do mundo), novos shift opcodes (para compatibilidade Ethereum) e melhorias de segurança da Federação, entre outras. Nossos lançamentos sempre são divulgados em nosso blog (https://blog.rootstock.io/noticias/), e uma lista mais detalhada dos recursos de cada nova versão é publicada em nossa página de marcos no Github (https://github.com/rsksmart/rskj/milestones).

 

Como o rootstock se compara a outros projetos similares de cadeia lateral do Bitcoin?

Existem apenas outros dois projetos de cadeia lateral de Bitcoin que estão atualmente ativos: o Liquid e o drivechain do Truthcoin. o Liquid é uma cadeia lateral federada, de certa forma semelhante à RSK. O Liquid visa a ser uma rede de compensação entre as bolsas que estabelece uma conexão entre as bolsas de criptomoedas, permitindo transações de Bitcoin mais rápidas. É otimizado para um caso de uso único. A RSK é muito mais genérica e programável, com contratos inteligentes estáveis. A RSK também é altamente compatível com aplicativos, bibliotecas e cadeias de ferramentas Ethereum. Tem um grande ecossistema e desenvolvedores treinados. Atualmente, os aplicativos Liquid dependem de uma biblioteca única fornecida pelo Blockstream e têm um ecossistema de nicho.

Outra diferença fundamental é que o Liquid usa sua Federação para o consenso de blocos, enquanto a RSK usa a mineração por mesclagem e atualmente tem cerca de 40% do hashrate do Bitcoin. Portanto, a RSK conta com segurança “termodinâmica” real. Qualquer pessoa pode participar da mineração de mesclagem da RSK, portanto qualquer pessoa pode receber taxas de transação.

Com relação à taxa de transferência da transação na cadeia, a RSK pode alcançar um volume maior do que o Liquid, essencialmente porque as transações de pagamento da RSK são menores que as do Liquid. Entretanto, atualmente a taxa de transferência de transação na RSK é limitada por seus mineradores, o que pode aumentar ou diminuir o limite de bloqueio de gás. Nas próximas atualizações da rede RSK, podemos ver dois desenvolvimentos importantes implementados: o protocolo LTCP (consulte RSKIP53) e o processamento de transações paralelas (consulte RSKIP04). Juntas, essas melhorias possibilitam um aumento de 30x na taxa de transferência da transação na RSK. Outra diferença fundamental entre a RSK e o Liquid é que a paridade da RSK é aberta. Ela pode ser usada por usuários individuais sem passar por uma bolsa e um processo KYC. No entanto, a maneira mais rápida de obter RBTC ainda é trocar os BTCs em uma bolsa de criptomoedas, pois leva um dia para transferir bitcoins para a RSK por meio da paridade. Em termos de segurança da Federação, o Liquid usa um multisig 11-de-15 com um gasto de emergência de 2-de-3, enquanto a RSK usa um multisig 8-de-15 — ou seja, cada cadeia lateral tem diferentes trade-offs entre disponibilidade e segurança.

O drivechain do Truthcoin está atualmente rodando apenas como um testnet, porque requer um soft-fork do Bitcoin para rodar na mainnet, então por enquanto não é realmente um projeto no qual se pode construir aplicativos. No entanto, compartilhamos com o Truthcoin a visão de longo prazo de que as cadeias laterais devem passar de um modelo federado para um modelo descentralizado.

 

Por que o RBTC é listado nas bolsas?

Listamos o RBTC nas bolsas para facilitar o acesso dos usuários menos técnicos. Como eu disse, leva quase um dia para transferir BTC para RBTC usando a paridade. Os usuários precisam, pelo menos, de pequenas quantias de RBTC para pagar taxas de transação, necessárias para a execução de contratos inteligentes. Esperamos mais demanda pelo RBTC à medida que mais usuários começarem a usar a plataforma.

 

A Ethereum vai mudar muito nos próximos anos. O que você acha sobre a Ethereum 2.0 e especificamente sobre os planos de usar eWASM em vez de EVM. Qual é a estratégia da RSK?

Acho que o apoio a uma máquina virtual aprimorada é uma boa estratégia de longo prazo, não porque a Ethereum (ou qualquer outro blockchain) deveria ser um “computador mundial” (não deveria), mas porque certos elementos primitivos criptográficos que são pedras angulares dos protocolos de pagamento de 2ª camada mais escalonáveis e privados precisam de mais processamento dentro da cadeia do que o que a EVM pode fornecer. A EVM deve permanecer interpretada ou transpilada para compatibilidade com versões anteriores.

A EWASM pretende ser um compilador WASM JIT determinista aplicado por consenso e contabilizado por recursos, e isso é algo difícil de se fazer. O design ainda está sendo modificado, precisa de revisão por pares, uma especificação clara e várias auditorias de segurança. A EWASM ainda está longe de ser um marco de estado beta.

A estratégia da RSK (detalhada em seu whitepaper oficial) era de fornecer compatibilidade com a EVM ao implementar uma VM baseada em bytecode de java, com transpiling dinâmico de códigos EVM em bytecodes de java. Pesquisamos e desenvolvemos nosso protótipo de VM, ma,s quando lançamos a RSK, compatibilidade com a Ethereum era nossa principal prioridade. Assim, adiamos a nova VM. Enquanto isso, a equipe da AION fez um excelente trabalho e lançou a AVM baseado em java, que está em estado de produção. Agora, estamos avaliando a possibilidade de propor à comunidade RSK o uso da AVM como a nova VM, e podemos colaborar com a equipe do AION na padronização da AVM.

 

Qual é a estratégia de escalabilidade da RSK? Você planeja algo parecido com uma fragmentação ou acha que a RSK já é escalável o suficiente para que as pessoas possam simplesmente criar cadeias filhas tipo Plasma e material de canal de estado para seus aplicativos? Se a RSK já for escalável o suficiente, quantos tx/s você pretende suportar após a implementação do Unitrie?

No laboratório de pesquisas da RSK, avaliamos novas propostas e trabalhamos frequentemente nos métodos de escalabilidade.  A estratégia de escalabilidade de longo prazo ainda não mudou muito desde que a RSK foi lançada. A principal prioridade é reduzir o máximo possível os recursos consumidos pelas transações dentro da cadeia. Por quê? Porque todas as soluções de camada 2 precisam de procedimentos de emergência em que os usuários devem entrar na cadeia para se submeter a arbitragem em caso de disputas. No caso de redes de canais de pagamento, a publicação dos últimos estados em janelas de tempo limitadas é fundamental. Se a capacidade dentro da cadeia for baixa demais ou se os custos de transação forem muito altos, os usuários mais pobres (que estão realizando transações com valores menores) correrão o risco de perder seus depósitos bloqueados. Isso ocorre porque o custo de arbitragem será maior do que os valores bloqueados.

Por isso, desenvolvemos uma estrutura genérica e inovadora para dimensionar os blockchains: a escalabilidade da cadeia de encolhimento. É baseado no insight de que os blockchains podem ser compactados, e também que a técnica de compactação usada pode envolver interações com os usuários para reescrever partes antigas do blockchain. Isso significa que um bloco pode ser compactado após ser minerado. Isso é especialmente poderoso no caso de blockchains com VMs, para os quais compactar transações significa fornecer provas de execuções que são dispendiosas para gerar. Dois protocolos interessantes são MimbleWimble e Coda: ambos buscam comprimir o blockchain durante a mineração. O MimbleWimble é extremamente leve porque é baseado em criptografia agregável, e é ótimo para compactar um bloco antes de ele ser minerado. Pelo contrário, o Coda requer muito processamento pelos mineradores, e a consequência é que os intervalos médios dos blocos precisam ser longos.  A escalabilidade de cadeia de encolhimento pode atrasar esse processamento e a compactação pode ser baseada no mercado; o blockchain fornece incentivos monetários para a compactação. Também pode ser obrigatória: os blocos são compactados após um período predefinido. Um caso especial que é simples, porém poderoso, é a agregação de assinaturas. As assinaturas ocupam 70% do espaço de transações na RSK. Portanto, desenvolvemos o protocolo LTCP, que se encaixa na estrutura da cadeia de encolhimento. A LTCP remove assinaturas desnecessárias e também compacta as transações por meio de predefinições configuradas pelo usuário. Se a RSK aplicar a LTCP em uma atualização de rede, poderemos permitir que a rede de pagamentos RIF atenda a 10 milhões de usuários hoje, 100 milhões de usuários em dois anos e um bilhão de usuários em cinco anos, usando algumas projeções razoáveis sobre padrões de uso para redes de 2ª camada. E isso pode ser alcançado ainda permitindo que PCs padrão executem os nós completos.

Para avançar rumo a esse plano de longo prazo, sugerimos vários novos recursos para a próxima atualização de rede: aluguel de armazenamento (consulte 0RSKIP113), processamento de transação paralela (RSKIP04) e, para a atualização seguinte, LTCP e uma nova VM mais rápida. Cada um deles permite uma redução no custo dos pagamentos. Como a RSK está focada na inclusão financeira, pagamentos seguros, rápidos e baratos são nossa prioridade.

Agora, que tal dimensionar a execução de contratos? As cadeias laterais (ou fragmentos) RSK e computação verificável (e, especificamente, provas de conhecimento zero) são duas técnicas para o dimensionamento de execução de contrato inteligente que estão sendo avaliadas por muitas equipes de desenvolvimento de blockchain, e tenho certeza de que a melhor solução ainda não foi criada. Se a VM da cadeia for expressiva e rápida o suficiente, criamos as condições para que essas soluções sejam criadas sobre a plataforma RSK. Outras redes podem implodir porque a escalabilidade na cadeia não foi abordada de maneira correta ou porque foi abordada tarde demais. Com uma boa camada de cadeia, tudo é possível. Portanto, nosso foco agora é ter a infraestrutura de cadeia mais barata possível para permitir a inclusão financeira. Além disso, a solução Lumino de pagamento de 2ª camada para pagamentos RIF e outros projetos assumirão a liderança, trazendo mais soluções de escalabilidade de 2ª camada.

 

Podemos comparar o tamanho dos blockchains da Ethereum e da RSK? Ou seja, a cadeia da RSK está crescendo ao mesmo ritmo que a Ethereum?

A RSK tem um nível menor de atividade na cadeia do que a Ethereum, que é algo que você esperaria de um blockchain com um ano e meio de idade. Portanto, o blockchain é muito menor que a Ethereum. No entanto, antes da versão 1.0.0, o blockchain da RSK poderia crescer tão rapidamente quanto a Ethereum para volumes de transação iguais. Com o advento do Unitrie que faz parte da versão 1.0.0, o estado do blockchain é dez vezes menor. Por exemplo, o último estado mundial não consome mais do que 50 Mbytes. O atual estado da Ethereum consome cerca de 130 GB. É uma taxa 2.600 vezes maior.

 

Solidity não é a melhor linguagem (especialmente em termos de segurança). Vocês planejam adicionar outras linguagens (por exemplo, Vyper)?

Estamos estudando o uso da cadeia de ferramentas Java, assim como a compatibilidade com a AVM (máquina virtual AION). Java é a linguagem mais popular para as empresas porque é digitada e fácil de auditar. É uma ótima escolha para redigir contratos inteligentes seguros.

 

O pessoal do IOHK está desenvolvendo cadeias laterais do tipo KEVM. Eles defendem que, com a estrutura K, fica muito mais fácil verificar formalmente a exatidão de um código de contrato inteligente. Agora, a Ethereum 2.0 rodará em uma EVM. Talvez seja uma boa ideia não tentar ser 100% compatível com eles e implementar alterações que possam tornar o blockchain do tipo EVM melhor do que a implementação da Ethereum. O que você acha disso tudo?

O IOHK está desenvolvendo o IELE, uma máquina virtual que facilita a verificação formal. É algo que ainda está em andamento, mas tem o benefício de se integrar à cadeia de ferramentas do LLVM Compiler. A AVM possibilita um vasto ecossistema de bibliotecas e ferramentas Java existentes. A EWASM tem o benefício de ser a linguagem mais popular dos navegadores web, por isso será rápida. E posso continuar debatendo os prós e contras de cada VM no nível do opcode. Mas é óbvio que ainda é muito cedo para escolher uma vencedora!

A RSK veio para ficar. Foi criada para usar a melhor tecnologia disponível, e essa tecnologia pode vir de equipes externas, e não da equipe de desenvolvimento da RSK. Isso significa que, se observarmos que existe uma força de tração e uma comunidade que constrói soluções em torno da IELE, AVM ou EWASM, também podemos propor a integração na RSK. Não tenho medo da possibilidade de executar várias VMs em um nó. Elas são fáceis de encapsular. Mas suponho que em 20 anos haverá apenas uma VM preferencial, e os demais bytecodes da VM serão transpostos para ela.

 

Quero fazer algumas perguntas sobre o seu post “O Retorno dos Negadores e a Vingança de Patoshi”:

1. A) Quanto tempo levou para fazer essa pesquisa?

Se você quer dizer toda a pesquisa sobre os blocos de Satoshi, começou em 2013 (e ainda continua), mas, no todo, suponho que não tenha dedicado mais do que alguns meses de trabalho.

1. B) Como você descobriu as “três falhas relacionadas à privacidade” para correlacionar os blocos? Foi uma mera leitura do cliente precoce ou há algo além disso?

Apenas lendo o código-fonte original e fazendo as perguntas corretas. Também contei com a ajuda de muitos membros da comunidade, que forneceram boas hipóteses. Em momento nenhum eu estive sozinho.

1. C) Concluída a pesquisa, você acha que isso foi justo ou que poderia mudar a opinião sobre Satoshi? Por quê?

Acho que foi o mais justo possível. Patoshi minerou a quantidade mínima de moedas necessária para manter a rede em operação. A quantidade de moedas coletadas é um mero resultado do tempo que levou para que o mundo conhecesse e confiasse no Bitcoin.  Assim que a rede se tornou sustentável, parece que ele parou de minerar. Além disso, o fato quase incontestável que Patoshi gastou não mais do que USD 5,00 (no valor histórico), tem um significado profundo de humildade. Na verdade, sempre achei que os blocos de Patoshi haviam sido marcados de propósito. E o propósito é transmitir essa mensagem para gerações futuras.

1. D) Na seção Nonce Restriction em todos os blocos Patoshi, você falou sobre uma prova que encontrou para verificar o padrão de outras formas. Você poderia comentar sobre como conseguiu a prova?

As provas matemáticas disponíveis são suficientes. Se as pessoas ainda assim não quiserem acreditar, então não há nada racional que podemos fazer para mudar isso.

1. E) No fim do artigo, você afirma que “há evidência que liga os padrões de Patoshi a Satoshi, com base em fontes públicas de informação e o blockchain”. Você poderia comentar a respeito disso? Como é possível ligar o padrão a Satoshi?

Fácil: siga os blocos.

 

Como que o $RIF token acumula valor? Meu entendimento é que as pessoas podem usar o RBTC para pagar por serviços de terceiros na rede RSK. Portanto, o $RIF token me parece de certa forma desnecessário.

Embora o RSK Live Mainnet exija – e sempre exigirá – que a execução de contratos inteligentes seja paga em smartBitcoins (RBTC), mantendo total alinhamento de incentivos com o Ecossistema Bitcoin, os Protocolos RIF OS visam a criar uma camada de infraestrutura fora da blockchain, que seja inicialmente construída sobre o Ecossistema RSK, mas futuramente integrada com outras plataformas habilitadas para contratos inteligentes, como a Ethereum e a EOS.

Para isso, é importante ter um token que seja neutro para qualquer uma dessas redes e cujo preço seja definido de acordo com a oferta e demanda de serviços de infraestrutura, independentemente do preço específico da criptomoeda nativa da rede (RBTC, ETH, EOS, etc.). Do ponto de vista do usuário, isso não representa nenhum atrito adicional, pois esperamos que, no futuro próximo, as DEXs (Bolsas Descentralizadas) ofereçam conversão instantânea entre as moedas nativas das Redes onde os Protocolos RIF OS sejam integrados ao RIF Token. A portabilidade do RIF Token criará economias de escala e fortalecerá a antifragilidade do ecossistema descentralizado como um todo, dando mais um passo rumo à concretização da Internet do Valor. O principal motivo é que nossa visão de longo prazo para o RIF OS é de um Marketplace unificado para serviços de infraestrutura fora da rede, que possam ser consumidos por todas as criptoeconomias habilitadas para contratos inteligentes (por exemplo, RSK, Ethereum, EOS, etc.). Nesse contexto, ter um token portátil/neutro pode ser considerado um benefício.