A Plataforma Arc

Original article in English here.

Quando fundamos a DAOstack no início de 2017, tínhamos dois insights principais a respeito de DAOs. O primeiro era que Organizações Autônomas Descentralizadas (DAOs) eram o uso mais importante do blockchain após o uso como moeda. E o segundo foi que era impossível prever como se pareceriam esses DAOs, e que eles sofreriam uma rápida evolução. Como consequência, decidimos construir o Arc, que é uma plataforma genérica para DAOs na rede Ethereum.

A ideia central do Arc é que seja uma plataforma modular, facilmente aprimorável, que permita uma seleção natural rápida de sistemas de governança. Estamos criando uma biblioteca aberta de componentes interoperáveis que permitirá que novas organizações sejam construídas de maneira rápida e fácil. Isto é um pouco como o modelo WordPress para sites. Nós escolhemos nomear Arc após a palavra grega arc (arq-).

Arquitetura

A arquitetura é provavelmente o maior desafio na construção de infraestrutura. Precisávamos construir uma plataforma que fosse flexível o suficiente e que se coubesse em todos os diferentes tipos de organizações e ideias relacionadas à governança. A palavra chave de novo era modularidade. Após um processo longo e interativo, a versão atual do sistema assumiu este formato:

Primeiramente, observe-se que cada caixa na figura é um contrato: para ser preciso, eles também podem ser contratos proxy + lógicos. Os três contratos à esquerda são o token, a reputação e o avatar, os quais chamamos de atores ou órgãos. Token provavelmente não requer nenhuma explicação, sendo o caso de uso mais popular da rede Ethereum, mas reputação e avatar precisam.

Um avatar é o rosto de uma organização na blockchain, por exemplo, se a organização quiser deter a propriedade de qualquer coisa, como a propriedade sobre um contrato ou ativo, o endereço será o do avatar.

Reputação requer ainda mais explicação, pois pessoas interpretam a palavra “reputação” para coisas muito diferentes. Em Arc, a reputação representa seu poder de decisão em um determinado DAO. Ela é unidimensional, o que significa que há um mapa simples entre endereços e números. É muito semelhante a um token, com duas diferenças principais: primeiro não é transferível, e segundo pode ser concedida ou retirada pelo DAO.

No lado direito da figura, temos os esquemas os quais são peças simples de lógica que compreendem as diferentes ações que podem ser executadas dentro de um DAO. Um exemplo é um esquema da IOC, segundo o qual um agente que envia ETH a um DAO recebe em troca tokens da organização. Outro exemplo é um esquema de financiamento de propostas, no qual todos podem sugerir e votar propostas, e se uma proposta for aprovada, ela será automaticamente financiada.

Na parte inferior, vemos as restrições globais. O conceito de restrição global é quase forçado quando consideramos a lógica modular, pois geralmente queremos impedir que os módulos quebrem certas regras abrangentes. Um exemplo é um limite para a reputação total possível de uma organização, ou uma taxa máxima de gravação dos fundos de uma organização.

Em seguida, temos o controlador, que é um módulo de controle de acesso. Ele mantém um registro de todos os esquemas registrados em um DAO, bem como as permissões para cada esquema. Além disso, mantém o registro de todas as restrições globais e as aplica revertendo as transações que violam qualquer uma delas.

O último tipo de componentes são máquinas de votação, também chamadas de módulos de governança. Esses componentes permitem a modularização do processo de tomada de decisão, permitindo iterações rápidas e o desenvolvimento de tais módulos. O principal tipo de máquina de votação implementada hoje é baseado no protocolo do Consenso Holográfico, o modelo central da DAOstack para governança descentralizada.

Reciclagem de Código e eficiência de gás

Uma das primeiras questões a se considerar na construção de uma plataforma de contratos inteligentes é a questão da reciclagem de código. A criação de componentes compartilhados tem muitas vantagens, mas também gera desafios nas áreas de complexidade, segurança, eficiência e facilidades de uso adicionais. Duas abordagens principais podem ser consideradas.

Uma é a abordagem de contrato como serviço (CaaS). Neste conceito, um único contrato é usado para atender muitas organizações / agentes. Como exemplo de um CaaS, pense em um contrato de várias siglas que mantenha saldos para qualquer grupo que deseje usá-lo, em vez de cada grupo implementar seu próprio contrato. Isso economiza muito gás na implantação, já que o contrato só é implantado uma vez para todos usarem. Deve haver simplemente um parâmetro adicionado a cada transação, indicando a qual carteira se refere, o que pode ser feito com um custo de gás muito baixo. A principal desvantagem da abordagem CaaS é que ela torna o contrato um pouco mais complexo, o que pode ter um custo de segurança. Além disso, pode criar desafios ao construir a interoperabilidade entre contratos, já que o padrão blockchain é que um endereço representa alguma “identidade”, e aqui temos um único endereço representando várias identidades.

A segunda abordagem para a reciclagem de código é a abordagem de proxy. Nessa abordagem, está-se implantando um contrato lógico junto com contratos proxy que apenas fazem DelegateCalls ao contrato lógico. Essa abordagem custa menos gás na implantação do que manter um contrato separado com toda a lógica para cada instância, mas custa um pouco mais em cada transação, devido à adição do delegate Call. O custo do gás da delegate Call é mais problemático em chamadas de “transferência”, que são limitadas a 2300 gases (um problema para o qual recentemente propusemos uma correção no Github). Outra desvantagem da abordagem de proxy é a complexidade adicional na codificação e especialmente a inicialização do contrato.

A versão atual do Arc usa a abordagem CaaS. Estamos no processo de pesquisar intensivamente a abordagem por proxy, tanto pelas razões mencionadas acima quanto porque essa opção também aumentaria a capacidade de atualização, (que por sua vez também tem suas próprias desvantagens e complicações).

Segurança

A principal vantagem de um sistema modular é que é muito mais fácil de auditar e de assegurar, uma vez que peças simples podem ser examinadas e testadas completamente. Isso não é uma garantia, obviamente, mas é uma abordagem para contornar o problema. Essa abordagem foi colocada à prova em uma auditoria intensiva de especialistas da ChainSecurity, à qual o Arc passou.

Em todo caso, nossa principal abordagem de segurança no DAOstack é o teste pelo fogo, o que significa colocar o código no mundo real, com dinheiro real, com a intenção de que as pessoas tentem quebrá-lo e assim nos ajudar a encontrar bugs. Pretendemos aumentar lentamente o montante de recursos em nosso contrato, à medida que ganhemos a garantia de que estão seguros.

Roteiro

Arc ainda é uma versão alfa, que está sob o codinome Genomics. O próximo grande lançamento, sob o codinome Genuine, contém principalmente melhorias nas áreas de modularidade e capacidade de aprimoramento. Está previsto para o segundo trimestre de 2019, embora no ritmo atual é provável que seja lançado mais cedo.