DeCon: Decentralized Construction

#0034: Se a indústria AEC é fragmentada e isto vem a ser uma das raízes das dificuldades de produtividade, por que não utilizar essa fragmentação para solucionar problemas? Blockchain e Smart Contracts pode ser uma saída?

ETH to the top (1/7)

Se você chegou agora na Newsletter e não sabe o que estamos falando saiba que o que vamos apresentar nos próximos tópicos diz respeito ao seguinte objetivo: utilizar a rede descentralizada do Ethereum para pensar um protocolo como o ERC 721 (Non-Fungible Token) para a construção civil armazenar informações dos fabricantes de produtos e assim utilizar a hash gerada pelo blockchain do Ethereum como um IfcClassification.

Ufa. Para tanto a sopa de letrinhas aumentará: DeFi, DAO, ETH, GAS, Smart Contracts... quando o mundo já estava complexo a coisa só piora.

Participando de alguns eventos nas últimas semanas e cruzando informações com o que vamos estudando tive uma epifania que tem bastante a ver com o subtítulo da newsletter no qual a solução da complexidade da indústria AEC pode estar na própria causa desta complexidade, ou seja, a fragmentação.

Lendo um pouco mais a fundo sobre a sopa de letrinhas acima é que decidi me aventurar por essas bandas e criar meus próprios Smart Contracts e fazer alguns testes interessantes com eles (utilizando a rede beta, não a original), no fim é tudo um processo de adaptação das tecnologias.

Para entender a jornada deste conteúdo, vamos primeiro definir alguns conceitos:

O que é DeFi?

DeFi, ou finanças descentralizadas, são aplicações baseadas em contratos inteligentes e blockchains que fornecem serviços e produtos tipicamente associados ao sistema financeiro tradicional, como empréstimos e negociação de valores.

O que é DAO?

Um DAO, ou Organização Autônoma Descentralizada, é uma empresa criada para ser executada por código no blockchain. As pessoas que possuem tokens associados ao DAO são responsáveis por votar nas alterações e propor novas ideias para manter o DAO ativo, funcionando e melhorando.

O que são ETH?

ETH nada mais é do que Ether, a criptomoeda baseada na rede Ethereum.

O que são GAS?

GAS refere-se à unidade que mede a quantidade de esforço computacional necessário para executar operações específicas na rede Ethereum. Uma vez que cada transação Ethereum requer recursos computacionais para ser executada, cada transação requer uma taxa. O gás refere-se à taxa necessária para conduzir uma transação com sucesso no Ethereum.

A princípio, DeFi e DAO não fazem muito sentido na sequência deste conteúdo, mas é bom entender estes conceitos para fazer mais sentido aquilo que falava nesta newsletter sobre OpenConstruction, ou seja, entender como funciona o mercado financeiro e até uma organização decentralizada nos ajuda a imaginar o que pode ser uma DeCon (Descentralized Construction, cunhada agora 😁).

Já ETH e GAS fazem bastante sentido porque para criar os primeiros Smart Contracts na rede do Ethereum não tem como o fazer sem essas siglas.

Smart Contracts (2/7)

Lá no texto sobre “A Tokenização da Arquitetura e Engenharia” demos algumas definições sobre este tema.

Descendo um pouco mais o entendimento destes conceitos, precisamos pensar o que é um contrato no Ethereum e o que é uma transação, vamos lá:

Contrato

Na forma como testei no que estou chamando de DeCon, o contrato seria um centralizador de informações, ou seja, um endereço (hash) de um fabricante ou empresa que irá registrar seus produtos na rede descentralizada. Sendo bem ridículo na explicação, pensa que isto é um arquivo de Excel em que teremos as informações dos produtos da empresa em cada coluna.

Transação

Na forma como testei no que estou chamando de Decon, a transação seria a coluna do arquivo de Excel, ou seja, é nela que temos as informações do produto. O código do produto passaria a ser o hash da transação.

Uma das grandes vantagens do Blockchain é que ele é imutável (desde que você proteja suas chaves..), obviamente quando Vitalik Buterin pensou no Ethereum talvez ele não estava pensando em produtos da construção civil, faria mais sentido utilizar o Ethereum como um contrato inteligente de uma casa ou algo mais tangível.

Materializando (3/7)

Bom, deixando mais claro o que falei no tópico anterior, isto aqui é um contrato no Ethereum (versão beta):

O contrato possui um nome, um compilador, várias outras informações importantes, mas a informação mais importante é esta aqui: 0xd94D225a0625bDB5Ed2390b9C0B0c03dC3AD6858

Através deste endereço 0xd94D225a0625bDB5Ed2390b9C0B0c03dC3AD6858 podemos saber todas as transações (produtos) que uma empresa possui no mercado:

Txn Hash é o código a ser aplicado nos produtos, ali temos o seguinte:

• Item A) 0x5b3bd76c4df763b24254b9b7d211897ca12c67caf2d679ae88d7f3c9bebc4990

• Item B) 0x315114972b2e6a404990a2ed490f21be43e6c90b261627b94075e682ba56d23c

• Item C) 0xaec44c5026d841e9ab2d7aecef7e20aceb27a8612eeb2d0c6da2b2da886f13b6

• Item D) 0xb580203e74d665de73648c15dd01db050e2ac357737de66e325eb3902c9c6e67

Por exemplo, isto é o que encontramos dentro do Item A:

Repare que o input Data são os campos que eu escolhi criar e preencher esta transação, são essas informações:

Isto foi o que me veio na hora, mas a ideia é tentar em algum momento evoluir para uma certa padronização de informação da indústria que já existe, até porque não faz muito sentido ter as mesmas informações para todos os tipos de elementos da indústria. Um exemplo do que quero dizer:

Claro que mesmo utilizando as informações de um IfcDoor para criar uma transação algumas coisas precisariam ser revistas porque não faz nenhum sentido ter GlobalId ou OwnerHistory na rede (bom.. não a princípio.. vai saber se lá na frente não faz sentido..).

DeCon (4/7)

Já que uma transação pode receber qualquer tipo de informação definida por mim no meu SmartContract, alguns caminhos podem se abrir para estudo.

A ideia que mais me chama atenção para direcionar esforços é a possibilidade de enriquecer um modelo de dados com as informações das hashs que especificam o produto. Por que acredito que isto seja um bom caminho? Bem, um dos grandes problemas da fragmentação é que todo mundo que tentou resolver ela tentou resolver sozinho (e fracassou miseravelmente).

Mesmo as classificações da indústria necessitam de um órgão centralizador para criar, cuidar e manter uma classificação, vide a Omniclass. Talvez pensar um protocolo como o ERC 721 para a indústria da construção não seja de todo uma má ideia. Hospedar isto na rede do Ethereum até pode ser um problema, mas já explico motivo.

São várias as dificuldades de centralizar este tipo de conteúdo e um deles é que a arquitetura de distribuição, criação de códigos e principalmente de sua validação fica limitada a capacidade de resposta da Omniclass, por exemplo.

Bah.. não se conveceu? Ok, troque Omniclass por ABNT que desde 2009 tenta distribuir uma tradução de classificação para o mercado, talvez esse seja um argumento mais forte.

Pensando em DeCon como uma DAO em que um arquiteto pode bater a hash do contrato da Deca e ver todos os produtos que esta possui  (desde que seja seguido alguns procedimentos de validação da codificação), meticulosamente podemos colocar uma condição para execução do contrato e assim finalizar o contrato mudando seu status para inativo ou coisa que o valha (aqui teria que verificar as possibilidades, pode nem ser esta opção..).

O lado bom desta história: seguindo um protocolo como o ERC 721 em que sabemos quais as informações necessárias para a “transação”, não há necessidade de uma ABNT, o próprio fabricante solta no Blockchain e gere o contrato que todo mundo tem acesso, realizando um scan na rede é possível agregar tudo junto e saber o que se refere ao protocolo DeCon.

Falo do ERC 721, mas acho que precisaria ser algo um pouco mais complexo do que isso.

Problemas (5/7)

O principal problema de pensar algo nesta linha esta no GAS para publicar as coisas no Ethereum, que digamos não é algo muito barato hoje em dia.

A rede do Ethereum é bastante conhecida por ser robusta, mas que possui algumas limitações de número de transações por segundo e um custo alto para que essas transações ocorram.

Nos testes que eu fiz estava custando algo como R$ 5,52 por transação com o ETH na faixa dos U$ 4,5k. Se a trajetória do ETH seguir a do Bitcoin e bater U$ 60k estaríamos falando de um custo de aproximadamente R$ 73,6 por transação.

Particularmente eu não gosto de modelos de negócios e/ou operacionais em que não haja uma previsibilidade de custos. Construir uma solução no terreno do vizinho é a pior coisa que você pode fazer.

Criptomoedas são muito imprevisíveis ainda em relação aos seus valores, uma saída que não testei e está nas tarefas futuras de aprendizado seria migrar a ideia para a Solana, rede que já nasceu para solucionar este tipo de problema e que pode transacionar muito mais coisas por segundo. Vamos estudar e voltar aqui em algum momento para falar sobre isto.

Obviamente a questão de segurança sempre é relevante pois para publicar os contratos e realizar as transações é preciso ter uma carteira com suas chaves. Tendo experiência em como os fabricantes gerenciam as informações de seus produtos a chance de dar algum problema é de 1 em 1.

Claro que interfaces e a experiência do usuário deve ser muito levado em conta, afinal, se eu não colocar o link do contrato que eu criei aqui ninguém vai conseguir nem acessar o contrato pra entender o que eu estou falando.

Não existe bala de prata, o que existe é estudo e trabalho, vamos estudando que com certeza vamos ter mais milhões de problemas pela frente.

IfcHash (6/7)

Quando falei sobre incluir a hash em um modelo de informação estava pensando em utilizar isto como um sistema de classificação de verdade.

Sendo assim, o que eu creio que poderia ser feito seria algo como utilizar o IfcClassification para guardar esta informação dentro de um IFC:

No limite da loucura desse negócio um fabricante poderia publicar uma contrato com o número de série de fabricação e o número de produtos fabricados no lote. Cada venda poderia ir descontando o valor de produtos do Smart Contract e as transações seriam registradas nos ERPs e modelos da vida.

Aí neste caso acredito que já fica uma pouco mais difícil de utilizar o IfcClassification, talvez propor para a BuildingSMART criar uma classe IfcHash com o IfcRelHash fazendo o relacionando das coisas, vai saber.

Muita viagem, mas também só de começar aprender Solidity já foi uma loucura por completo. Talvez pensar em código de especificação descaracterize o IfcClassification, ir na linha de um IfcRelDefinesByType poderia ser melhor? Talvez, mas no fim para simplificar fica algo como isto:

Proposições (7/7)

O legal sempre de tentar tirar um conceito do papel é que você vai enfrentando dificuldades dia sim e dia também para tentar solucionar um problema.

Menos do que ter uma chave pronta procurando uma fechadura para abrir, acredito que explorar mais a fundo as possibilidades seja um boa coisa a se fazer, daqui um ano posso voltar aqui nesse texto e dar risada das ideias aqui colocadas como também posso chegar na conclusão de que a loucura não era tão grande assim.

Vamos explorando o mundo de SmartContracts, Blockchain, IFC e afins e tentando evoluir as ideias por aqui. Se quiserem conversar sobre isto também podemos bater um papo.

Seguindo a linha blogueirinho, se gostou do conteúdo não deixe de seguir o canal e compartilhar a newsletter com seus pares 😊

Obrigado e até a próxima,

Abs.

Tiago Ricotta

Publicado em 08 de Dezembro de 2021 às 20:40