 e nós estamos sendo livestreams no YouTube. Great, thanks, Shawn. Só para fazermos um apanhado geral, Malta conseguiu instalar as dependências como nas instruções de preparação do workshop, podem escrever no chat ou fora, se quiser. Explante, Shawn, se conseguires correr o jar no run de configure e funcionar, está feito. Também temos um setup rápido com o Dev Container, depois vamos fora um bocadinho. É parte mais tríquia. Olá, bem-vindos, Rafael, Sérgio. Ok, vamos deixar Rafael trabalhar no problema com a Mic. Bem-vindos a todos para o workshop do Hyperledger Cacti. Interoperabilidade e Blockchain com Hyperledger Cacti. A gente realmente aprecia todo mundo nos ajudando hoje. E estamos muito felizes de poder fazer esse workshop em português. Eu nunca desrespeito o seu idioma por tentar... Sim, eu vou fazer isso realmente rápido. Obrigado, Rafael, por criar esse programa de treinamento. A gente realmente aprecia isso. E estamos muito felizes de poder experimentar isso. A gente também está streamando no YouTube. Se alguém gostaria de compartilhar isso com amigos, eles são mais do que bem-vindos. E eu vou incluir no YouTube um link para os pre-requisitos. Mas Rafael, tira isso. Obrigado, John. Eu vou te perguntar para compartilhar os slides no final, se possível, talvez no description do YouTube. Sim, vamos compartilhar os slides no description do YouTube, e eu acredito que a gente vai poder enviar uma mensagem para todos os atendidos que assinam. Ok, muito bom. Eu vou then switch to português. Boa tarde a todos. Bem-vindos ao Workshop de Interoperabilidade com Hyperledger Cacti. É o primeiro workshop em português sobre interoperabilidade na Hyperledger. E neste workshop vamos falar um bocadinho de interoperabilidade, como é que funciona nas várias blockchains do nosso projeto, que é o Cacti, que é um projeto dedicado à interoperabilidade. Interoperabilidade, ao fim ao cabo, possibilidade de um conjunto de sistemas de software funcionarem juntos. Portanto, partilharem dados, fazerem a execução com base no estado de outros sistemas, e portanto, é uma área de investigação bastante interessante. Para já, porque os sistemas são diferentes em limites, segurança, descalabilidade, privacidade diferentes, por outro lado, é uma área que está em constante evolução, e é especial no mundo da blockchain. Portanto, este workshop vai ter a participação, a minha participação, a participação do André Augusto e da Mónica Gomes, que fez um grande trabalho a pôr este workshop pronto para vocês. Eu gostaria de vos pedir-me, antes disso, fazer uma pequena introdução. Pronto, eu estou a trabalhar no projeto Cacti desde março de 2020, portanto, não sou inception, ainda não se chamava Cacti, nem Cactos, era blockchain integration framework, e também sou um estudante de autoramento no Instituto Superior Técnico, que é uma universidade portuguesa, na qual me tento especializar, porque às vezes é difícil, a interoperabilidade e a segurança, um câmbio que está em constante evolução. Também vou para o MIT no âmbito desta investigação, portanto, no projeto Cacti nós temos um protocol que é o SATP, que antes se chamava ODAB, que é um protocol de transferência de assets entre networks, e portanto, essa foi uma colaboração com MIT, que agora está na Internet Engineering Task Force, e portanto, poderão ver que este tipo de projetos tem para as oportunidades muito interessadas, e também trabalha na blockchain como engenheiro de investigação. Pronto, apenas uma pequena referência à blockchain, e como ela complementa o Cacti, o Cacti providencia a senso a vários blockchain na sua maioria permissioned, ou seja, blockchain privadas, em que os participantes têm de ter permissões especiais para normalmente escrever. Enquanto que a blockchain providencia acesso a blockchain públicas, então a nossa ideia para fazer aqui um casamento agradável é providenciar o acesso a iubiquati, que é um produto blockchain, que é processante API para blockchain públicas, através de um plug-in do Cacti. Ou seja, o Cacti vai ter um plug-in que vocês podem utilizar para acceder a um conjunto de blockchain públicas. E no final, o que isso providencia é o acesso a blockchain públicas e privadas num local apenas, o que é muito interessante. Também temos a Mónica Gomes, que vai falar sobre, vai fazer uma introdução ao AI para o AI de Cacti, ela é estudante de mestrado no Instituto Superior Técnico, também estudante de aeropropilidade, e este ano foi a mentora, a mentora não, menti, mentoranda, do Programa de Testagem de Hyperledger, nomeadamente contribuiu para este workshop. E vamos também ter o André Augusto, o André Augusto fez um mestrado no Instituto Superior Técnico, agora está a fazer o doutoramento, também neste ano de interopropilidade. Ele desenvolveu um bastante afim, que deve dizer o plug-in do ODAP, que agora é o SATP, portanto um protocol de transferência de assets entre blockchain, e também vai ter a oportunidade de apresentar alguns dos exemplos que temos aqui no Cacti, para vocês verem como é que o código funciona e tal. Portanto, nós vamos dividir o nosso workshop em duas partes. Na primeira parte, é um bocadinho mais teórica, digamos, portanto estamos falando da preparação do recogitório, introdução a Hyperledger, introdução a interopropilidade. Vocês veem que temos aqui alguns projetos relacionados com o Cacti, Weaver, UI e Firefly. Na verdade, não vamos falar desses projetos neste workshop, porque os apresentadores já falaram deles no workshop em inglês, tanto eles não falam português. Portanto, vocês quiserem aprender um bocadinho mais sobre estes projetos relacionados, tem o workshop em inglês, tem a gravação para ver. Nós vamos saltar essa parte, vamos falar diretamente sobre o Cacti, para algumas das componentes do Cacti, incluindo a arquitetura de desenvolvimento, os plug-ins, o Weaver, o servidor API, que é um plug-in muito importante, OpenAPI, a metodologia OpenSource nos usamos e ambiente, teste e execução. Portanto, no final da primeira parte, já vão conhecer bastantes coisas e estar preparados, esperamos nós, para aprenderem sobre os exemplos práticos. Serão dados na parte 2, portanto, vamos falar de alguns exemplos de aplicações que podem fazer com o Cacti, alguns mais simples, alguns mais complexos, falar um bocadinho sobre o futuro do projeto e fazer um Q&A, portanto, as vossas perguntas. Se vossas estiverem perguntas, por favor, vão pôr um ponto no chat, eu vou estar atento e vou responder na medida que vossas as fazem. No entanto, para termos uma discussão assim mais fluida, mais focada, vamos utilizar o Q&A. Ok, portanto, parte 1, ok, building. Primeiro, temos de construir o projeto para podermos executar o código para ver como é que funciona e, para isso, tem a SQL Code, que vai dar as instruções de build-by-parallager-cacti. Ops, que está aqui. Portanto, se vocês forem aqui ao repositório do yparallager-cacti, ainda não mudámos o nome, no GitHub, vocês têm aqui a estrutura do projeto e têm um documento que é o build.md e aqui tem todas as instruções para instalar todas as dependências Inclusive, há alguns vídeos no YouTube que mostram algumas das componentes, portanto, tem tudo em tie, comando a comando para correr tudo bem. Nós estamos a estes procedimentos em Ubuntu, 20.04, portanto, se tiveram um Mac que estão capazes de encontrar algumas dificuldades. Obrigado, André, por proporzar o link. Pronto, mas nós temos uma maneira um bocadinha mais rápida e fácil de fazer a coisa, portanto, em vez de instalarem as dependências, uma a uma, que nós vamos pôr aqui os comandos, podem usar o Def Container. O Def Container é uma funcionalidade do yparallager-cacti, permito construir o ambiente de execução. Vocês precisam utilizando um Docker Container para correr dentro do VSCode. Portanto, basicamente, você inicializa o Def Container e ele vai demorar algum tempo a instalar as dependências todas e no final tem um ambiente de execução pronto. É só executar os fichores do projeto, os exemplos etc. Pronto, eu vou explicar como é que nós usamos o Def Container. Ok, se calhar ainda antes de irmos para o VSCode mas fora aqui no Browser Pronto, primeiro é obter o projeto, é o Passer. Vão aqui ao yparallager-cacti, tem aqui um botão do Fork, carrega no Fork, eu já fiz o Fork, mas vocês selecionam aqui a vossa conta clicam Create Fork e depois vocês vão para uma página que contém o vosso Fork que é a vossa versão do código que tem, pronto, um ponteiro para o repositor original. Vamos reparar que o nome do meu Fork é diferente porque na altura chamava-se assim já foi há algum tempo. Pronto, depois vocês vão aqui a Code, copiam aqui esta referência ao repositorio e depois obtém o repositorio. Como é que fazem isso? Pronto, eu basicamente fiz um git clone da referência ao meu repositorio git não tenho de fazer ela outra vez e obtenho a codebase que já está aberta. Também convém adicionarem o remote do cacti podem fazer isso fazendo git remote ad upstream e depois a referência ao cacti. Esta aqui é a referência que usa SSH pode usar HTTPS se ficaria assim. Ou seja, vocês ficam com o repositorio local que aponta para o vosso Fork chamada Origin e a upstream que é o código que está no main codebase digamos assim. Agora, se nós quisermos usar o tal DefContainer nós vamos aqui em cima view e depois extensions procuramos por DefContainer e depois instalamos esta extensão aqui no install pronto, depois já pedi para fazer Reload se carregarem fnf1 abrem aqui o menu dos comandos pode fazer Reload e ele exatamente acontece isto ele detecta um DefContainer e vocês clicam em reopen in container ele vai abrir este DefContainer vai construir o fichão desculpem construir o container que aponta para este código e depois vão poder utilizar o ambiente da execução construída basicamente o que ele faz é construir este Dockerfile que tem todas as dependências necessárias para o cactipe instala Python instala curl instala windows tk que é um dos connectors que nós temos instala uma data de coisas faz uma data de configurações muitos dos passos que estão no ci.sh que está aí algo não interessa muito agora e portanto instala um ambiente de desenvolvimento todo esta é a maneira rápida de fazer a coisa vocês podem fazer podem construir este código construir o ambiente de execução à medida que vamos apresentando o workshop portanto preparação rápida é fazendo este processo é a preparação manual tem de instalar o git o gs, curl, npm tem de utilizar as vossas versões de vários packages tem de instalar o Docker um que pode instalar com o comando que está e verificar a instalação normalmente há alguns problemas de instalar o Docker a primeira preparar o projeto para estar pronto a executar de algum trabalho portanto por isso é que recomendamos que se use o devcontainer instalar um ambiente stk e depois o Java etc etc etc no final, quando tiver as tendências todas instaladas, tem de correr o comando ear um drone de config um gigante que vai instalar primeiro vai passar transpilar o type script em javascript e vai correr todo um conjunto de configurações para preparar o código a ser corrido até posso exemplificar o que ele faz portanto no package.json também tem os scripts e definição das dependências para o projeto depois temos vários subprojetos dentro da diretoria packages temos um conjunto de scripts que fazem coisas diferentes o configure que vocês usam no drone vai instalar as dependências e vai construir o back-end o que é construir o back-end o script build back-end onde é que está aqui então depois corre isto o que é que isto corre? ele faz lento o projeto corre o script clean temos de ir em cima e vermos o clean pode ser ver que corre isto pois gera código a partir das especificações openAPI vamos falar um bocadinho disso mais à frente gera o javascript na diretoria dista a partir do typescript e faz uma data de coisas mais portanto é um projeto bastante complexo mas depois quando formos cada package individual e dos exemplos vai ser mais perceptível o que está a acontecer pronto, uma coisa importante nós temos um conjunto de scripts e utilitários que ajudam no desenvolvimento no teste na excursão dos vários componentes do cacti vocês vêm aqui a .vscode esta diretoria e vão reparar que tem este ficheiro template.launch.json vocês vão fazer é duplicar este ficheiro portanto podem copiar e postular e renome-á-lo para launch.json ok quando vocês fizerem isto e se verem aqui ao run-and-debug vão ter agora um conjunto de scripts que os permitem neste caso, correr no ficheiro em específico ok, e nós vamos usar isto nos ficheiros de teste. Vamos voltar à apresentação pronto, isto é os passos vocês têm de seguir para preparar o projeto para ser executado por favor vão fazendo à medida que eu vou falar se tivarem isto feito depois na final podem acompanhar os exemplos que é bom sim, depois quando chegarmos à parte dos exemplos, os exemplos ainda não estão na main codebase quando estiveram portanto, quando fizerem clone do código os exemplos devem estar nesta diretoria, deveriam estar examples cactus workshop examples 14 novembro este código não vai estar disponível porque os brand que contém este código ainda não foi incorporado na main codebase mas vocês podem ter acesso a este código mesmo, pois mostres como se faz pronto, mas daqui a uns dias semanas esta diretoria já vai estar presente no código principal na main brand do repositório do cactus às vezes é difícil ser accurate a introdução é hyper ledger a fundação hyper ledger foi criada em 2015, já tem uns anitos faz parte do Linux Foundation e um dos objetivos principais é fomentar o desenvolvimento de blockchain ou distributed ledger estes projetos são open source quer dizer que nós e quantos desenvolvedores podemos analisar o código de cada um dos projetos modificá-lo utilizá-lo para os próprios projetos e portanto a hyper ledger tem um conjunto de projetos e portanto não há hyper ledger blockchain por assim dizer, como por exemplo uma FIA mainnet ou uma Polkadot mainnet ao invés disso, hyper ledger providencia a tecnologia e cada um de nós as organizações podem fazer o deployment de diferentes soluções portanto nós temos de configurar primeiras blockchain e depois criamos as reis portanto há vários projetos há bastantes projetos, não vai dar tempo para falarmos todos mas alguns podemos salientar é por exemplo o hyper ledger fabric já tem bastantes anos, é um dos primeiros que eu utilizei na minha tese e também num curso sobre o blockchain que está no hyper ledger temos o hyper ledger indie que é dedicado à identidade digital com a utilização de decentralized identifiers e verifiable credentials temos o hyper ledger Bezo que é um cliente do ethereum portanto vocês podem se conectar a várias redes ethereum através do Bezo, podem ter as voces redes privadas que correm basicamente uma ethereum virtual machine portanto esses projetos que estão em uma fase bastante sólida e depois temos projetos que estão em incubação portanto projetos que ainda não têm um nível de maturidade social para serem considerados graduate, mas que estão nesse caminho portanto nós somos um deles o que é que está e que é dedicado a interopabilidade temos o caliper que é dedicado a testagem de smart contracts em diferentes plataformas que eu utilizei na minha tese de mestrado portanto permito-vos saber quais são os bottlenecks dos vossos smart contracts permito-vos saber qual é o throughput que vocês conseguem alcançar qual a latência etc tem o hyper ledger firefly que é para construir aplicações que usam vários blockchain tem um objetivo similhante ao que é que está ai mas não exatamente igual tem o solang que é um compilador de smart contracts em sólida tipo para diferentes outras plataformas temos a orsa que é uma coleção de primitivas criptográficas critas and rust e mais além de os hyper ledger projects temos uma coisa que é chamada os labs que são espaços de investigação de construção em que vocês podem submeter o vosso projeto que usa tecnologias hyper ledger e ao ter feedback da comunidade e ter um sítio onde vocês podem trabalhar em conjunto com outros membros da comunidade um desses projetos é o nosso curso sobre blockchain que chamamos enterprise blockchain technologies que está nesse link aí abaixo basicamente é um curso que introduz os fundamentais em sistemas de tribuírios, criptografia, segurança, hyper ledger fabric não tem um módulo de interoperabilidade mas faz uma introdução à tecnologia blockchain e temos outro projeto que exemplificamos aqui, que é o blockchain carbon accounting que essencialmente é uma iniciativa para promover transparência da missão de CO2 de oxídeo carbono por parte de diferentes entidades utilizam várias blockchain tem um diagrama de sequência que exemplifica um dos flow e nós usámos este exemplo no nosso paper sobre sistematização de interoperabilidade tenta aqui vários projetos diferentes muito interessantes podem consultar pronto, nós temos uma wiki da hyper ledger foundation temos um calendário de reunhões públicas portanto vocês podem participar em qualquer reunhão de qualquer projeto qualquer reunhão pública claro inclusivamente do cacti tem dois tipos principais de reunhões temos as reunhões dos maintainers na qual se discute direção do projeto algumas das issues os pull requests etc e temos outro tipo de reunhões que são as per programming meetings que são basicamente eu gosto de pensar que são mini aulas dadas pelo peter em que ele ajuda a esquecer qualquer nuvida que tenham dentro do projeto portanto se desenvolver código ou perceber como é que o projeto funciona são literalmente mini aulas e são todos os dias durante 15 minutos dadas pelo peter, o peter é um dos fundadores do projeto eu recomendo bastante a que vão lá pelo menos eu aprendo bastante lá pronto e também temos programas de mentoria da fundação todos os verões temos uma fase de submissões em que os eventores podem assumeter o projeto e depois temos uma fase de candidaturas em que alunos profissionais recentes profissionais digamos candidato a esses projetos e tem uma grande pra trabalhar num desses projetos durante o livrão a tamónica trabalhou num projeto que pretendia criar o workshop a tamónica fez o seu mentorship aqui há muitos outros projetos portanto desde estender e trabalhar nos blockchain a criar aplicações blockchain a desenvolver tecnologias novas como interoperabilidade ou estágios mais de investigação portanto é uma grande variedade de estágios lá pronto, vamos agora falar de interoperabilidade dar uma pequena introdução a área e mostrar a nossa sistematização da área para vocês se perceberão um bocadinho mais como é o que é que está aí se tem quadra em comparação a várias approaches diferentes de fazer interoperabilidade portanto, como já dissemos interoperabilidade é a capacidade de vários sistemas de trabalhar em conjunto nós definimos três modos de interoperabilidade a transferência de dados transferência de assets ou ativos ok transferência de dados é basicamente quando temos dados ou estado numa blockchain e queremos transportar esse estado por outra blockchain portanto, aqui não temos de assegurar invariantes como no double span ou seja nós podemos copiar e colar maneira livre, não temos de nos preocupar com nada entre aspas pois temos de transferência de ativos e aqui já temos de nos preocupar com algumas coisas portanto, quando nós transferimos um bem de uma blockchain para outra, imagina em transferir bitcoin para o Ethereum para usarmos o bitcoin na rede Ethereum o que nós fazemos na prática é bloquear ou dar a log ao bitcoin na rede bitcoin e depois com base na informação que nos diz que esse evento aconteceu criar uma representação do bitcoin na rede Ethereum ou por outras palavras um asset sintético um ativo sintético e portanto isto não viola no double span porque nós criamos um ativo sintético mas este ativo está backed up pelo ativo na blockchain original que está bloqueado que não pode ser utilizado portanto na prática, criamos uma moeda baseada numa moeda na moeda original que está bloqueado e portanto acabamos por ter apenas uma moeda no total em circulação se nós pudéssemos de alguma forma não respeitar esta regra portanto utilizar a mesmo a moeda criada na rede Ethereum e utilizar o bitcoin original isto é problemático pois a representação não está backed up e pode perder o seu valor e de facto é o que acontece em alguns ataques nós vemos a acontecer em bridges que são soluções de interoperabilidade que permitem transferência de ativos e depois temos troca de ativos em que temos na literatura as chamadas atomic swaps que nos permitem eu posso trocar bitcoin com andré eu tenho bitcoin, eu quero isser posso trocar com andré, o andré tem isser quero bitcoin de maneira atómica pois já posso explicar como é que funciona para avaliar as soluções de interoperabilidade nós usamos dois conceitos os p levels e os c levels e para a potencialidade e estes níveis dão-nos a intuição para uma pergunta que é será que o sistema consegue interoperar com outros tal como ele é? diz-nos quanto mais sistemas o nosso conseguem interoperar com nativamente e depois temos a compatibilidade que é a capacidade de interoperabilidade ou de interoperação de ambos portanto como bem é que um par de sistemas conseguem interoperar portanto e podem ir para uma pergunta à medida transferenciados é muito simples temos conjuntos de dados no blockchain de origem passamos esses dados para um iam, que é interoperabilidade tem uma solução de interoperabilidade e depois esta solução de interoperabilidade vai fazer uma transação contra uma blockchain out uma target blockchain e no final temos uma replicação de dados isto não é muito difícil de fazer imaginem que eu tenho um smart contract no ethereum que pode ser por exemplo criptoqueries imaginem que temos um registro global de todos os gatos que existem todos os gatos que foram aumentados nós podemos ter o nosso blockchain hyperlogic e podemos ter replicado essa informação é simples, basta ter um servidor centralizado que aceda ao ethereum, pode ser através do infior ou pode-se ter o seu próprio nó leia desse smart contract leia do registro e depois faz uma transação com os dados que leu para a nossa rede hyperlogic há um exemplo simples de uma transferência de dados depois temos uma transferência de ativos imagina que eu tenho isser e quero transferir o isser para blockchain out então eu do lock deste isser e depois do unlock do mesmo asset na blockchain out e depois temos a troca de ativos que é implementada com uma tecnologia chamada HDLC, este Time Lock Contract em que essencialmente temos duas partes em duas blockchain uma das partes que é iniciante faz deployment de um smart contract que contém uma transação de um ativo para a outra parte só que esta transação está protegida por um segredo e este segredo é o que é representado aqui pelo cofre ou seja, a Alice queria o smart contract transfera transfera ativos para o Bob mas só se o Bob providenciar a chave vermelha até agora relativamente simples então o que o Bob pode fazer é faz deployment um smart contract na outra blockchain que transfera ativos para Alice se a Alice providenciar essa chave esta chave é um segredo e nós vemos representado como uma fechadura no cofre e essa fechadura no cofre na verdade é a ash do segredo a Alice agora pode providenciar o segredo estancar o cofre portanto tem acesso à transação que envia assets na segunda blockchain e o Bob agora opteva chave como tem um smart contract e a Alice tem que providenciar a chave ele agora lê esse input e tem acesso a chave então quer dizer que ele agora pode usar essa chave na blockchain A para destrancar a transação que envia os assets para ele portanto, aqui há duas transações uma transação na blockchain A que envia os diálices para o Bob e uma transação na blockchain B que envia os ativos do Bob para eles pronto, agora temos os níveis P para potencialidade então eu tinha vos referido que os níveis P era uma maneira intuitiva de vocês perceberem como fortemente é que o sistema de interoperabilidade consegue interoperar com os outros e o nível P1 é o mais fraco, o nível P4 é o mais forte basicamente se temos um sistema de providencia nível P1 de interoperabilidade quer dizer que a nossa solução de interoperabilidade consegue suportar funcionalidade interoperação entre funcionalidades da mesma subnetwork da mesma network do mesmo protocol na prática interoperação entre smart contracts da mesma blockchain o nível P2 já é interoperação entre subnetworks diferentes por exemplo entre Ethereum Mainnet e Ethereum Gorlin entre Deltinetworks diferentes entre redes Deltinetworks diferentes, é o nível P3 corresponde a interoperação por exemplo entre uma rede Hyperledger Fabric privada e outra rede Hyperledger Fabric privada ok, portanto já temos que ter aqui alguma sincronização entre os entre os nós mediado normalmente por uma off-chain party mas o protocol ainda é o mesmo que é Hyperledger Fabric hoje temos o último nível que é o P4 que é entre protocolos diferentes por exemplo Placadote Ethereum Hyperledger Fabric Bitcoin e Hyperledger Bezo portanto aqui já temos que ter em conta todas as diferenças entre as infraestruturas blockchain pronto, nível C level permite-nos saber como bem é que um par de sistemas funciona em conjunto e nós definimos três níveis primeiro nível é interoprabilidade semantica ou seja, se dois sistemas conseguem comunicar nós temos de um mesmo protocol por exemplo um protocol de transferência de ativos portanto, se eu consigo comunicar dois sistemas e eles conseguem transferir um bem quer dizer que conseguem seguir o mesmo protocol, quer dizer que têm interoprabilidade semantica pois temos a camada organizacional que é o nível C2 que basicamente diz-nos que dois sistemas conseguem trabalhar juntos para obter um mesmo objetivo para realizar um mesmo objetivo é executar agreements legais legais não, portanto, agreements entre organizações normalmente são legais mas não necessariamente não tem de ter a teoria binding falta-me algumas palavras em português desculpa e portanto na última camada, um nível C3 é se dois sistemas conseguem interoprar e respeitar as regumamentações e leis que regem esses sistemas por exemplo fazer transferências de ativos com caráter legal e binding conhecido pelos governos que é um caso mais difícil nós observamos que muitos sistemas C1 nós temos e funcionam mas C2 já não há tantos e C3 que nós saibamos praticamente nenhum aqui o António pergunta se temos suporte ao que tentaremos adicionar e eu acho que sim eu acho que sim eu acho que nós pretendemos adicionar suporte mas não não tenho certeza é difícil ter uma visão completamente de todos os packages do projeto mas eu tenho impressão que sim porque nós temos uma dependência no IPerlager Indi um psico aqui pelo menos há uma Indi Test Network eu acho que o Carbonacal tem exemplo de uso o Indi não sei até que ponto é que é que temos um suporte muito extenso ou seja só usado em exemplos mas pelo menos existe a dependência no projeto pronto, excelente, muito obrigado André portanto temos algum suporte sim portanto continue a mandar aí as perguntas e sim, temos muitos desafios de governance no que tocar esses sistemas, reparem nós quando temos a nossa rede blockchain temos uma governance mais ou menos centralizada as redes públicas é mais notório em que os nós escolhem se querem executar as novas versões do software e portanto acabamos por ter a palavra de todos embora na prática os developers acabam por ter bastante peso é uma questão de conseguir esconvencer os teus pares que o software quer usar para aquele blockchain é aquele e não outro caso não aconteça nós temos os tais forcos em que nos participantes chegam a uma versão do código e outros participantes chegam a outra versão do código nas blockchain privadas a governance é mais fácil porque temos uma quantidade participantes a partir da muito menor mas mesmo assim ficamos com alguns desafios de governance e quando nós fazemos interoprabilidade dentro de blockchain não é completamente óbvio coisa porque agora temos não só de sincronizar a nossa própria rede mas também uma rede terceira uma rede terceira e o próprio mecanismo de interoprabilidade pode ser executado por os membros de uma blockchain ou idealmente das duas ou até uma terceira parte portanto há aqui muitos desafios que nós ainda nem temos bem a certeza de questão porque a nossa área ainda está muito no início pronto e depois nós no nosso paper que fala dos níveis P e dos níveis C nós propomos uma maneira de escolher uma solução de interoprabilidade portanto nós temos aqui nível do lado direito da tabela em cima P1, P2, P3, P4 C1, C2 e 3 e depois temos data transfers essa transfers e essa text changes que corresponde à transferência de dados transferência de ativos e troca de ativos e nós categorizamos cada uma das soluções que encontramos em grupos de acordo com as suas capacidades em termos níveis P, C e do modo de interoprabilidade imagina que nós queremos uma solução que provendencia a nível P4, C1 e transferência de ativos vamos aqui às colunas de P4, C1 e transferência de ativos e vemos onde é que tem o TIC, a setinha o OK que são as três últimas linhas nós depois, se pusmos aqui ao grupo das soluções e esses níveis que estão são referências no paper e essas referências providenciam esse esses níveis P, C e essa transferência é a maneira que nós encontramos de intuitivamente, de forma não super específica de referir as capacidades de cada uma das soluções de interoprabilidade que nós encontramos portanto há muitas há soluções que para já praticamente todas as soluções dão nível P4 porque reparem, não é muito útil ter soluções de interoprabilidade explícitas para nível P1 porque normalmente todas as botes anis assegura o nível P1 nativamente e depois podemos também ver nesta tabela que a maior parte das soluções se foca em essa transferência basicamente é transferir o meu Bitcoin para rede Ethereum, transferir o meu Ethereum para rede Polkadot, etc portanto as bridges as pontes de ativos são as soluções mais usadas de interoprabilidade por agora mas nós achamos que podemos ter soluções muito mais genéricas para transferir dados condicionalmente condicionalmente e transferir bens condicionalmente portanto há aqui muitas possibilidades portanto se quiserem aprender um bocadinho mais sobre estas maneiras de ver as soluções de interoprabilidade temos aqui uma talk nossa no Hyperledger Global Forum e temos aqui dois fapres que nós fizemos também sobre a área ok acho que a Mónica não está Mónica não está Mónica ia falar sobre o Hyperledger Cacti mas como não está eu vou falar se ela aparecer entretanto nós mudamos e continuei a pôr perguntas por favor pronto Hyperledger Cacti é uma das ferramentas do Hyperledger tenta conectar várias blockchain através de sua arquitetura baseada em plugins é um projeto open source como é usual e como é regra na fundação Hyperledger tem mais ou menos 70 contribuidores 250 stars uma data de forques tem colaboradores da IBM, da Accenture da Fujitsu da nossa universidade em Lisboa da BlockDemon uma data de identidades não só de universidades mas também de empresas portanto é providencia infraestrutura de nível empresarial portanto infraestrutura resiliente para use cases que envolvam vários blockchain e também para investigação portanto se forem alunos estiverem a fazer os vossos teses é uma infraestrutura bastante útil portanto nós criámos o cacti porque nós percebemos que há muitas blockchain diferentes que estão a aparecer constantemente protocolos e que este não interoperam nativamente portanto nós queremos conectar esses protocolos para permitir criação de novos use cases e um bocadinho pela aventura de perceber o que pode acontecer de bom dessa transformação se vocês cansarem bem a própria arquitetura da internet teve uma evolução semelhante no início a internet era composta por pequenas redes locais essencialmente utilizadas para comunicações militares e para comunicações entre universidades e com o passar do tempo estes local network areas evoluíram para internet começaram a conectar-se umas as outras começámos a ter internet service providers a aparecer a cometer redes cada vez mais afastadas, umas das outras e ao fim de umas décadas temos a internet que é utilizada por praticamente toda a humanidade e que teve um ponto de inicio bastante pequeno portanto se nós fizermos esta comparação nós percebemos que a interoperabilidade por um lado ainda está nos seus dias muito iniciais e por outro tem um potencial uma potencialidade de abrangência muito grande e para permitirmos que isto aconteça temos de envolver ferramentas de infraestrutura para os desenvolvedores e o cacti a uma delas o repositorio do cacti o cacti está naquele link já vos mostrei temos um 8Pay para também que vai ser atualizado à medida que o cacti que é o projeto que estamos a falar chamava-se Cactus e o cacti é a junção do cactus e de um projeto Hyperledger Labs chamado Weaver e eu vou falar um bocadinho disso na arquitetura nós temos um servidor Discord e depois temos lá até Cactus ou Cacti precisamente qual é que é em que podem conversar conosco perceber por lá dúvidas espero programing sessions também são no canal Discord etc ok, a estrutura temos no nosso repositorio uma data de diretorias que é algo overwhelming no início mas quando vocês perceberam o que isto faz fica até bastante simples temos a Dev Container para vocês construiram o projeto temos o VS Code que tem alguns scripts que já foi um bocadinho temos alguns exemplos alguns muito complexos, outros um bocadinho mais simples incluindo os que usamos neste workshop temos a diretoria das packages portanto o cactus é um projeto que tem algumas componentes core e depois vocês podem usar vários packages que são plugins e juntá-los às componentes core portanto no final podem ter uma web app que servem vários dos plugins que vocês necessitam e isto é tudo muito dinâmico e funciona de uma maneira muito modular também há uma diretoria importante que nós referimos aqui que é das tools que temos por exemplo as test lagers que são blockchains de teste que nós podemos inicializar de maneira programática e também destruir e manipular para não só testagem das várias packages como também para propósitos educacionais vamos falar sobre estas test lagers pronto e com o cactus podemos realizar vários exemplos, podemos por exemplo ter blockchains privadas que geram dados médicos, pacientes em que os nós destas redes são por exemplo hospitais companhias seguros e outras empresas que representam os pacientes temos por exemplo transferências de ativos alguns use cases utilizando blockchain em que usam smart grid em que os nós são produtores de energia e conseguem vender essa energia uns aos outros através de uma rede blockchain que permita acelerar o processo de settlement das transferências que são feitas, das compras e vendas que são feitas de energia pronto, mas nós temos muitos use cases no white paper que envolvem várias blockchains que são muito menos use cases dos que vocês têm só como blockchain então podem ver o white paper para mais depois temos a arquitetura de desenvolvimento ou seja como é que agora passamos a parte um bocadinho mais técnica como é que o cactus, o cactus eu estou em modo cactus durante muito tempo e como é que o cactus se organiza em termos de arquitetura nós temos basicamente dois modos que são as setas laranja e azul no modo laranja temos uma componente principal que é chamada o cacti node e o cacti node tem um servidor api basicamente é componente main que recebe os pedidos de vários plugins desculpem de vários utilizadores e os reencaminha para os plugins e basicamente serve os requests esses node servers são centralizados e portanto que vocês podem ver do lado esquerdo connectarei é um dos plugins que é chamado pelo node server o node server recebe um request ele vê se é para o conector A ou B sobre para A, manda o request para a esquerda e pronto, esses connetores podem ter vários servia vários protocolos normalmente um conector serve um protocol e tem mais código para fazer diversas funções em cada uma das redes cada conector junta-se a uma rede blockchain podemos ter um conector para o Ethereum um conector para o Polkadot um conector para o fabric e depois nós configuramos esses connetores para que se junta a uma rede em particular o outro modo é a comunicação descentralizada usando uma metodologia peer-to-peer em que nós temos aplicações standalone que recebem pedidos do utilizador final e esses pedidos podem ser enviados para outras aplicações que usam outros plugins através de o que nós chamamos os relays os relays são entidades operadas por qualquer membro que tenha permissão portanto, se forem relays de blockchain públicas é por qualquer um, se for blockchain privadas a partir dos relays tem algum nível de registro e eles reencaminham requests ok? pronto, nós vamos nos focar um carinho mais no node server, que é mais fácil de gerir alguma pergunta até agora? pronto, esta é a arquitetura portanto é mais ou menos o mesmo diagrama mas mostrado de outra perspectiva em que temos node servers por exemplo, o node server na parte baixo da figura comunicar com uma blockchain core da R13 e com uma blockchain Ethereum e isto é centralizado podemos fazer, neste caso asset exchanges podemos fazer data sharing entre o fabric e um enterprise system of record portanto, um sistema centralizado o cargo dos pod e faz conectar blockchain a sistemas centralizados não tem de ser necessariamente só entre blockchain e também podemos fazer transferências de ativos pronto, isto é o modo com node server mas também podemos ter com o modo relay em que esta comunicação é de relay para relay diretamente em vez de ser de node server para as redes pois cada um dos relays se comunica com a sua rede em particular pronto, nós temos várias metodologias que nos permitem ter um grau de resiliência de software que é bastante desejável para um projeto open source unidamente nós utilizamos testes, muitos testes portanto, nós temos um processo para contribuir código para o repositório que é baseado na integração continua em que para cada conjunto de packages para cada package cada componente de código que é produzida tem de ver correspondida com o conjunto de testes estes testes pretendem essencialmente dar segurança aos maintainers do projeto e também nos próprios que se nós alterarmos o código no futuro nosso projeto não vai deixar de funcionar nós temos uma aplicação exemplo que vai ser fora introduzida pelo André basicamente temos 3 blockchain e estamos a transferir dados entre cada uma delas temos um objeto uma classe de bamboo harvest que define uma cujeita de bamboo produzida dentro de uma rede que depois é transferida para uma rede forum e a classe bamboo harvest é consumida e é criada uma nova classe que é bookshelf representa a conversão de materiais matéria-prima-bruta bamboo em bookshelf e depois há uma transferência de dados transmite estes objetos de bookshelf para uma rede fabrica que por sua vez os consomem e criam um objeto shipment que representa o envio destes bookshelf ok vamos fazer a arquitetura plugins já estamos quase à esquerda arquitetura plugins do cacti permite-nos ter várias implementações para os vários protocolos e para as várias funcionalidades podem ser carregados dinamicamente e com pouca overhead portanto nós temos um conjunto de plugins core que tem o nosso servidor API e este cacti core podemos juntar podemos conectar vários plugins os ledger connectors que permitem conectar várias ledgers kitchain que permite fazer gestão de chaves e outro qualquer plugin queiram fazer nós por exemplo desenvolvemos um plugin para capturar process and transactions portanto basicamente esse plugin fica a observar diferentes ledgers e quando estas fazem transações captura os eventos que são criados e depois construem um repositório de process and transactions variado no comportamento que observa para que é que nós queremos isto bem nós podemos utilizar várias técnicas de data mining para pegar nesta lista de transações e criar modelos de comportamento do sistema portanto podemos fazer aqui coisas muito interessantes alguns exemplos dos packages de sistemas disponíveis é por exemplo cactus command que tem bibliotecas para login, de criptografia nomeadamente de assinaturas digitais criptografia de assimétrica temos o cactus core que permite o nosso plugin registry para criar plugins ao nosso API server temos keychain que permite gerir chaves embora este seja simples e essencialmente para testes temos ledger connectors que permite conectar a várias distribuidas ledgers temos por exemplo os plugins de teste vamos agora ver um bocadinho como estas coisas estão implementadas espero que consigam ver o vscode estes são os exemplos mas nós queremos gerar os packages nós temos muitas packages e se formos ver ao common o que temos aqui temos sempre a mesma estrutura temos os node modules específicos de cada um dos packages e neste caso nós instalamos estas dependências como não opcinais com dependências para desenvolvimento temos o código o código principal e o código de teste cactus core tem testes muito simples podemos passar a frente e falar uma coisa um bocadinho mais complexa no caso do código o que é que o que é que o cactus come a definir? podemos ir ao nosso index e o nosso index exporta tudo da nossa public API o package cactus core está a exportar estas coisas todas que aqui estão o que é que ele exporta? um logger provider um logger, opções para logger os vários níveis para descrever um logger quando nós temos um log normalmente podemos definir o nosso logger como mostrando apenas diferentes níveis de um nível específico normalmente info, warning, error debug etc e portanto esta coisa aqui ele vai diretamente ao package log level ok se virmos aqui ele está a exportar basicamente um tipo que é composto por outro tipo e estes tipos são números ou uma destas strings ok ou seja, nós vamos poder utilizar qualquer uma destas coisas para inicializar o log level description do nosso logger ok pois temos um signer, temos aqui utilitários para gerir chaps criptográficas etc pode explorar, vir cá regar no control no comando e ver o que é que está aqui exportado muitas destas classes são wrappers sobre packages terceiros ok nós queríamos esta classe que simplesmente faz algumas operações mais ou menos simples sobre uma biblioteca terceira que nós importamos ok o cross-chain transaction visualization é o plugin que fala aí das cross-chain transactions temos o connector os connectors temos o core ok em cada package temos um idmi que tem alguma documentação, pelo menos na grande maior parte dos packages e o que a package core tem é o registro do consórcio portanto nós podemos ter um consórcio do package node e mais alguns utilitários o plugin registry por exemplo que é basicamente um container que diz quais são os plugins que nós temos carregados a cada instante ok temos aqui métodos para obter a lista dos plugins que temos que temos no nosso registro encontrar um plugin por id encontrar um plugin por package name portanto se nós olharmos para nossa arquitetura do cacti este plugin é bastante útil porque nós podemos ter no mesmo servidor dois connectors para uma mesma ledger que estão a correr em portas diferentes para adicionar alguma resiliência se um deles crash nós podemos ao outro então quero dizer que o nosso plugin registry pode em runtime, dinamicamente encontrar um dos connectors para servir um pedido se eu quiser fazer uma transação contra o fabric o plugin registry pode simplesmente procurar um dos connectors que esteja disponível se um deles crashou, não há problema contra os outros pronto, depois podemos remover podemos adicionar basicamente é uma classe que faz gestão de nomes cada classe normalmente tem um logger depois podemos instanciá-la com um nível depois temos também um package que é bastante útil que é o test tooling e este package depine o utilitário que auxilia o desenvolvimento de packages do cacti e também packages que vocês criam portanto packages com um repositório específico ou dos packages core pronto, e este utilitário são test ledgers são principalmente test ledgers como podem ver aqui aerorra fabric e também outras tecnologias como postgres também há aqui um rabbit mq test server ou seja, vocês podem programaticamente instanciar um rabbit mq server e cliente e também nos vossas aplicações para termos test um container um container docker que tem um rust instalado substrate test ledger que é o ambiente de expressão de placado e muitas outras coisas nós podemos ver em específico o que é que acontece nas test ledgers mas já vamos a isso acho que tem algum texto de suporte pronto, antes das test ledgers nós podemos criar um registro podemos criar um registro com vários plugins podemos adicionar plugins dinamicamente e depois o nosso cactus node vai ter acesso vai ser servido no certe porto para um certe servidor tem uma interface e vai ter este registro pronto, o API server é então o plugin serve pedidos clientes e o André vai fazer um pouco disso no seu demo e este plugin principal barracor é gerido pelo node server vocês não têm de ter um API server no vosso node server no vosso cactus node mas é recomendado depois nós temos uma especificação o Open API para cada um dos connectors o Open API é um standard um formado que permite escrever, produzir, consumir e visualizar Web Services e portanto, essencialmente o que acontece é que nós podemos definir os nossos 100 points para cada um dos plugins e no final é gerado um cliente, um SDK para estes mesmos plugins com base na nossa especificação portanto, por exemplo no HDLC coordinator temos esta definição que depois vai ajudar a gerar code que nós podemos chamar deixem-vos mostrar-vos se verem aqui a swagger UI editor swagger.ui isto permite-vos visualizar a geração ou permite-vos visualizar o output de um dos ficheiros Open API eu colo aqui a definição que nós temos para o connector do fabric e ele diz-nos que nós temos um endpoint em slash API, slash V1 o Run Transaction que nos permite correr transações ele diz-nos quais são os argumentos que nós precisamos para o body que são estes todos e depois diz-nos qual é o output que nós vamos ter deste plugin de executar esse endpoint functional output Success e a transaction ID que é criada a partir da discussão dessa transação especifica eu vou mostrar este endpoint não se preocupe, vai ser mais claro depois temos outros get transaction de Ply Smart Contract etc etc e também definimos os esquemas para cada um dos objetos relevantes no nosso connector qual é a vantagem de isto, se vocês quiserem se vocês tiveram a vossa aplicação escrita em Rust ou em Go, por exemplo, ou em Python muita gente gosta dessas linguagens vocês podem pegar nesta especificação e gerar um cliente em Python ou em Rust ou seja, podem ter o vosso código e depois podem fazer chamadas HTTP com o connector que está a correr no servidor, por exemplo, Express que está a correr durante o time que usa JavaScript ou TypeScript, como, por exemplo, Node.js Node.js com Express e portanto, é uma maneira de conseguir integrar facilmente as vossas aplicações com infraestrutura cacti claro que, se a vossa infraestrutura já usar TypeScript JavaScript, não tendo estar a fazer chamadas HTTP, podem usar o código exatamente ou não, ou podem também gerar a API e fazer chamadas podem, perfeitamente, ter o vosso web server a correr no endpoint e os connectors a correr na outra porta e fazer chamadas HTTP ok, tis sim, vou mostrar um bocadinho de desta, desta coisa que estou para aqui a falar pronto, Ledger Connector Fabric eu gosto de falar deste connector por que contribuir um bocadinho para esta coisa vocês já sabem que a public API exporta todas as coisas interessantes que nós queremos que seja reutilizáveis, neste caso é o próprio connector, que é uma classe uma interface com opções para inicializar o connector temos também o padrão de desenho factory, portanto permite criar connectors on-demand e mais algumas coisas quesitas cada uma destas diretarias tem um ficheur de endpoint, permite definir um endpoint para que corresponde à definição que vocês viram no swag editor, ok, portanto vamos ter um endpoint para get block nós temos o de transação é específico, como é que era run transaction vamos ter um endpoint para run transaction e basicamente o que nós temos a dizer é que quando houver um um pedido para para este endpoint que pode estar a correr numa porta em específico a porta não está a hardcoded nós vamos correr este code do handle request o que é que o handle request faz simplesmente vai ao connector que nós temos distanciado para este endpoint em específico que vai correr o metetransact ok e o metetransact é o code que está responsável por fazer uma transação contra uma rede hyper logic factory, ok portanto ele vê qual tipo de transação e submete transação com base nos parâmetros que foram indicados também tem suporte para private transactions ok retorno no final lembrou-se que tínhamos ali um esquema para a resposta desta transação em específico retorno ao output retorno a um boleano o success e o transaction ID e vocês podem ver como é que esses objetos são gerados no final desconeta e pronto e fazemos login de coisas ok muito interessante nós vamos ver este code e correr ok há uma pergunta não ok vamos continuar ok este aqui é o que vos mostrei mas para o login do hyper logic factory sim portanto deixa-me só acrescentar uma nota que nós fazemos para cada package ok é quando nós corremos o configure ele constrói o código de todos os packages o code gen também é gerado para cada um dos packages portanto o code gen basicamente corre o generate sdk que usa este open api generator para ajudar o código o respondente a definição open api portanto temos o ficheiro open api.json aqui ok este é o código markup que eu coloquei e gera um client em type script ok e o código é posto naquela diretoria e depois nós vamos poder utilizar este código ok por exemplo, no ficheiro de teste do fabric v2 run transaction endpoint nós vamos criar uma testlager do fabric vamos criar um conector do fabric vamos criar uma fabric api que é gerado a partir do open api.json file e vamos fazer transações contra este api portanto vejam é muito simples criar este api o que nós fazemos é simplesmente instancial com as configurações e a única configuração que temos aqui é o path o api host que corre no localhost na porta na porta aqui fora atribuída dinamicamente quando o código está a correr o que é útil porque se não tínhamos de estar a fazer art code da porta e pode não funcionar por várias instancias ao mesmo tempo qualquer maneira vamos correr e ver isto mas por aqui um breakpoint depois vamos poder usar este fabric api através do object api client e reparem interessante nós corremos o api client dot run transaction v1 e este run transaction v1 a descer pronto isto é código gerado mas a corresponder a fazer um request para este endpoint que é servido por este coding portanto quando chamamos api client dot run transaction v1 ele chega aqui ao handle request e depois chama o method transact do connector essa é a magia que está a acontecer por trás claro que nós poderíamos simplesmente chamar o connector dot transact mas nós temos a fazer um teste end1 para testar também os apis que são gerados pronto e daqui a pouco chamamos de falar destes testes o que é que temos de tempo? acho que está mais ou menos o que era suposto se estresse projeto open source como é que nós podemos contribuir toda a gente pode contribuir apenas tende respeitar algumas regras que basicamente se traduzem ou se resume a respeitar os outros providenciar feedback construtivo ajudar quem sabe menos etc o chamado senso comum pronto incentivamos a irem a ajudar ele para programing meetings que são ocultas pelo peter está no canal do discord basta irem ao hashtag cactus e irem ao voce channel e acontecem todos os dias durante 15 minutos pronto quando nós fazemos qual é a maneira de contribuir pronto vocês imaginem que eu estou na branch do workshop ok mas vocês fazem quando do projeto vocês vão ter uma branch que é a main como é que vocês contribuem a code vocês fazem git checkout new branch falta aqui um nb ok vocês fazem alterações ao code ok por exemplo um espaço a mais não é particularmente útil pode ser adiciona o fichado e por exemplo uma mensagem de comid que também tem regras que está detallado nos fichados de suporte do otmd que estão no raiz do project cactus é o contributing do otmd dizem quais são os regras para nomear esses fichados ok fazem comid e ele não deixa o que é bom e ele não nos deixa e eu penso porque nós não mudamos nada apenas acrescentamos uma linha vazia pronto essa é outra coisa quando vocês fazem o comid é corrido uma utility que é o islint de erros se vocês têm erros ortográficos ou se não respeitam algumas das regras que estão programadas aqui como por exemplo o mt comid o que é bom pois vocês fazem git push origin e a vossa origin é o vossa fork e o nome da branch se vocês fazem push isso está vazio se calhar faz push de uma branch e depois vocês podem criar um pull request visitam este link e criam um pull request contra a main codebase e se vocês chegarem a essa parte podem falar com nós sobre mais tais como fazer isso agora vamos para a nossa branch e podemos tirar isto pronto quando vocês fazem o pull request vocês têm de escrever uma mensagem no correto do pull request que é ilustrativa do que vocês fizeram e vai haver um processo de revisão para os maintainers do projeto por exemplo o peter da akuma em que o vosso código é lido e vão ser dados para melhorar esse código e maneira a que respeitam as regras do projeto se vocês aprenderem a fazer código resiliente preparado para a produção e que esteja pronto para ser consumido por muita gente pronto e depois é um processo iterativo em que vocês podem rever esse código fazer alterações a esse código uma das coisas que vocês podem ter de fazer é alterar o código que fizeram ok e não criar necessariamente um comit um novo comit imaginem que vocês fazem uma alteração mais uma vez os façam em branco vocês adicionam a os states changes e depois em vez de fazer um comito novo fazem comito a manzesse pronto e depois a partir daqui se chegarem aqui nós explicamos o resto essencialmente quando chegam a este passo vocês podem alterar o nome do comito podem alterar o mensagem do corpo do comito ou podem simplesmente alterar o último comito para uma alteração que foi pedida pelo maintainer depois apenas tentam fazer push origin e a vossa branch esteja o workshop esteja a muitas coisas sobre o nosso processo de produção de código open source mas pronto mas está tudo feito de maneira a que vocês aprendam o máximo e de maneira a que sejam respeitados os standards de qualidade para este tipo de projetos pronto e além disso quando vocês sometem o vosso por request há um conjunto de testes automáticos que é corrido sobre o vosso código como santo por exemplo na leitura da vossa mensagem de comito portanto se tiver mal e depois ele corre todos os testes todos os packages para certificar que o vosso código, tanto o novo código que introduziram não reventa com o código que existe e portanto dá mais segurança em aceitar de novo código uma velocidade elevada portanto o código o fichero que fala deste processo é o contributing.md portanto aquele link é capaz de estar mal e também ter algumas métricas sobre as contribuições dos vários participantes ali ambiente teste de execução nós usamos docker para correr vários blockchains e portanto se estar cada um dos packages contra um ambiente de teste controlado e para isso utilizamos o local container images e os fiches test ledgers portanto qual é a ideia na package das tools docker temos as imagens das all in one test ledgers por exemplo do fabric basicamente tem fiches docker file que permite criar uma rede fabric uma rede pesos, uma rede corda indipenso que não uma rede substrate sim e depois nós utilizamos essas all in one images para criar docker containers que depois podem ser acedidos através de uns fichores que temos em test link portanto capítulo 1 all in one docker images ok construímos a image como podemos pôr no repositorio no nosso caso pômos no repositorio de imagens docker e depois nós obtemos essas imagens programaticamente através de ficheiros como por exemplo o fabric test ledger ok para os fiches tipo o fabric test ledger permite obter essas imagens e criar containers a partir das imagens a pagar os containers executar operações específicas da ledger tudo programaticamente portanto antes da nossa break vamos mostrar-te como é que isto funciona eu também tive a oportunidade de trabalhar um carinho nas test ledgers e acho que é bastante fixe portanto vocês trabalham com o kactite também vão aprender muito sobre o docker ok o direito all in one ledger o que é que nós temos este é simples nós temos a imagem em meio e depois temos um script um script que dá setup a uma porta a uma web socket uma porta web socket e depois executa este comando basicamente com o rumbinário em dev mode tem dois argumentos que são dados como input o que é que o docker file tem o docker file define algumas working directories define portas default instala algumas dependências podia ser mais simples e no final no final copia o start do otsh para dentro do container e depois no final corre o script instala dependências instala o ambiente tem o rust o asm instala o substrate contracts node da parity e no final corre o script ok então vamos ver como é que podemos correr isto vamos aos workshop examples que vocês não devem ter por agora mas há uma maneira de aceder em este código que é vão a rafael apb blockchain integration framework que é o meu clone vão a branches e workshop examples sim e aqui vão ter olha, está aqui a branch que fiz pus aqui vão ter acesso ao código que vou mostrar agora pronto se vieram em examples workshop examples source vão ter um exemplo que é test ledger e este test ledger criou uma substrate test ledger então o que é que isto faz vamos já ver se recebemos juntos o que é que isto faz pin 2 logger levels um id bug e outro info e vamos ter uma função test ledger que é escutada que é esta função ok criamos um logger fazemos logo de uma mensagem e definimos as opções de ledger, lembram-se que nós tínhamos nós dávamos como argumento ao docker container a porta uma porta, temos aqui definido e como é que vai lá ter, estas envars são carregadas como variáveis de ambiente dentro do container, portanto o container depois pode usar qualquer uma destas variáveis quando ele usar a porta ele vai correr na 99,44 também poderíamos adicionar aqui WS port mas nós usamos a padrão e temos esta imagestag o que é que isto quer dizer quer dizer que nós vamos chamar-o a substrate test ledger que tem este tag que foi post em março, no final de março este ano e depois nós inicializamos a ledger então vamos ver o código e correr estamos a formular isto é just, não então nós escolhemos o tap que é um test runner que consegue correr bem e corremos portanto isto vai executar este coding e ele vai parar nos breakpoints que nós definimos isso que é nós queremos ver antes fazemos docker ps, não temos nada a correr agora vamos ver como é que inicializamos uma test ledger temos aqui coisas estranhas portanto isto pode acontecer o fixe para isto é correr yarn durante watch basicamente pelo código temporal aqui um problema qualquer porque ele está aí para o JavaScript na vez do TypeScript isto acontecer corre o run configure e a partida vai ficar resolvido então vamos esperar um bocadinho que isto acabe mas essencialmente isto vai criar um object test ledger que está definido aqui test tooling substrate test ledger portanto há duas partes ao fixer TypeScript que gera os docker files e depois aos docker files as docker images a docker image foi publicada no repositorio public e nós vamos utilizar isto fixer o substrate test ledger para aceder esta imagem portanto quando nós criamos uma substrate test ledger o código que corre é o construtor portanto nós vamos inicializar a test ledger com uma data de coisas a image tag portanto se nós não idermos nada vai apanhar uma mais antiga e a imagem portanto se vocês veem este link é onde está publicada a imagem da substrate test ledger e depois vai correr o start portanto o start cria um cliente do docker se não tiver a imagem ou melhor se não idermos para não tirar a imagem ele tira portanto o containers.pull image vai ao registro a este registro e tira a imagem com este tag com o tag idamos ou com o tag padrão ele lembram que o docker file precisava de WSport ele vai as variáveis de ambiente e adquiria ou então usa padrão que foi feito em 9.44 mas há umas configurações não muito relevantes e depois ele cria retorno a uma promessa de um container ou seja, vai tentar executar container vamos ver se já temos sorte com isto acho que os delos dos demos não estão satisfeitos com ele também podemos ver o que acontece aqui no javascript e durante a break posso tentar ver o que está a passar construtor está a fazer a sign a todas as coisas isto na verdade não é muito interessante e depois acontece o start reparem que aqui no nosso terminal temos de logger já escrever coisas de inicialize de logger que é o que temos aqui e cria uma instância de a substrate test ledger que é o que acontece no construtor agora queríamos uma instância do docker portanto nós vamos ver se temos a imagem que imprimimos aqui pulem image tenta fazer a get dela e o resto das configurações pronto, basicamente basicamente o que temos agora depois do start ser executado com sucesso é a test ledger a correr imprimimos a mensagem e se nós formos aqui fizermos docker ps claro que temos aqui um docker container tem a imagem que nós definimos que está a correr uma substrate test ledger no final paramos o mesmo docker container e este é destruído o que é que isto permite fazer isto permite criar e destruir test ledgers e realizar algumas operações no caso de da test ledger relativo ao substrate não fazemos nada de muito complexo mas, por exemplo, na fabric test ledger já fazemos coisas um bocadinho mais complexas ou na beso test ledger temos falado da beso pronto, os fichas de testes são pontos de partida para perceber como o cáctus funciona porque tem a definição de todas todas as dependências que precisam ocorrer o watch e também mostra-vos como é que cria uma test ledger como é que a destrói o afterall binding corre o código e depois do teste ter sido concluído com sucesso pronto, e mostra várias coisas a funcionar vamos correr este teste isto é ingestion o que é que fazemos aqui em primeiro lugar corremos o start o fichar que é chamado é o beso test ledger e se repararem o código e semienta ao outro portanto ele obtém o nome da imagem que é esta cria uma instância do docker, tenta fazer pull mas já temos a imagem e retorna à promessa vai tentar criar um container com estas configurações vamos ter as coisas que podemos configurar e quando estiver a começar, quando for inicializado com sucesso, ele imita um evento e permite que a promessa retorne o lcheck configuramos coisas de servidor podemos fazer isto da frente set up de um plugin kitchain set up de um connector para o beso chamamos o uninit do connector obtemos uma chave privada e depois reparem que nós fazemos uma transação utilizando o nosso connector portanto, em vez de utilizarmos o beso API nós chamamos diretamente do connector e o que é feito aqui no transact vemos qual é o credential type do request o credential type é uma private key portanto, ele entra nesse case e corre o transact com private key o que é que isto faz corre todo o código que é necessário para fazer uma transação contra uma bot chain que é avm based portanto, usa a web free API que é bastante famosa under the hood assina a transação reparem que temos aqui uma transação assinada em vários formatos conseguimos assinar a transação com sucesso, corremos o transact basicamente, estamos a fazer uma transação o que é que nós estamos a utilizar estamos a utilizar esta private key este tipo este tipo é a private key estamos a adquirir a transação assim que tivermos zero confirmações podemos ter um número de confirmações maiores normalmente mais escuro é seis confirmações escolhemos a conta que estamos a utilizar para enviar um certo valor para outra conta e estas contas são definidas aqui em cima nós temos lembrou-se que eu vos disse que a test ledger fazia coisas mais interessantes na verdade esta test ledger além de podermos inicializar etc permite obter várias contas e criar novas contas test dinamicamente é uma test ledger mais avançada do substrate depois nós corrermos a nossa transação vamos ter este output transaction receipt e reparem o transaction receipt quero ver-me melhor aqui tem bloc hash no qual foi incluída no qual transação foi incluída temos o bloc number temos a conta que enviou o gás que foi usado a conta que recebeu e o resto de transação nós depois podemos e penso que vamos ter a transação pela hash que é precisamente o que fazemos e depois vamos ter esta response e devemos obter o mesmo ou seja, com a nossa test ledger a nossa test ledger permitiu-nos testar uma funcionalidade do conector que é a de executar transações alguma dúvida até agora se não há dúvidas vamos fazer uma pequena pausa de 10 minutos descansar um bocadinho e depois vamos parar a parte dos demos voltamos daqui a 10 minutos acho a 54 olá todos, acho que podemos resumir André, quero agora sim, podes passar tu portanto, nesta segunda parte vamos estalar das várias opções de deployment do cactus de os vários exemplos de aplicações que podemos construir e do futuro do projeto finalmente, para encerrar vamos ter uma sessão de perguntas e respostas vamos passar isto é relativamente simples as opções da arquitetura deployment são basicamente as várias opções que podemos tomar para fazer o deployment do Rapperless Cacti temos a utilização low resource indicada para testes locais para desenvolvimento dos packages etc é que essencialmente vamos ter um consórcio cactus nodes cactus nodes que corre dentro da mesma máquina portanto, temos a nossa máquina local executamos o nosso Fischer test e criamos dois cactus nodes ou melhor, dois membros cada membro pode ter um ou mais nós no caso temos um node, cada membro e este mesmo node é um container que pode ter um ou mais API server por sua vez, cada um dos API servers que reviraciona pedidos para o plugin em gestante e podemos ter para ter redundância plugins para um mesmo ou seja, perdão podemos ter diferentes API servers que apontam para o mesmo plugin connector então podemos esperá-los logicamente e ter um API server para um conector em específico e também para os plugins que gerarem credenciais desse mesmo conector isto permite nos ter alguma separação e maior segurança podes passar pronto, uma opção de deployment segue mais um padrão de produção é ter cada um dos membros a correr na sua própria máquina, que pode ser na cloud então temos cada um dos membros a ser servido por um load balancer corre dentro de um cloud provider e depois podemos ter um arranjo parecido algo que foi descrito na section anterior podes passar pronto, agora o André vai apresentar os vários exemplos da aplicação ok, então vamos lá a isso deixem e pronto, então vamos começamos com pronto, lá está temos de para ter acesso a estes exemplos temos de fazer aqui o set do repositório do Rafael como como remote eu tenho aqui uma refresh uma instalação do cactus refresh não tenho aqui ainda não tenho aqui nada e não tenho os a pasta dos workshops no teu objetivo se quiserem acompanhar agora e fazer isso à medida que eu for fazendo também podem fazer até podem aceter aqui este mais vale direitamente ao branco vamos ter aqui o link novamente e lá está vamos copiar o link para o repositório do Rafael estamos no nome qualquer por exemplo Rafael e portanto veem que nós já temos agora o repositório aqui vamos fazer por exemplo um guide feitos Rafael e isto vai buscar tudo aquilo que coberno naquele repositório o que nos interessa é este branco que está aqui os exemplos um guide deste branco vamos ver que tenho aqui o comito, o último comito dos exemplos e veem que já me apareceu aqui a pastinha dos exemplos do workshop o primeiro que nós vamos ver é este hello world basicamente é deixem-me por aqui novamente nos slides basicamente este hello world cria um API server lá dentro deste API server vamos expor um só plugin vai ser este cactus plugin object store IPFS uma rede IPFS quase uma key value store e este package que está aqui é um connector para uma rede IPFS e portanto todos os endpoints ou que são expostos por este connector vão ser expostos para este API server quando se olhamos aqui para o código temos de bois para cima temos o API server vamos ver o start de API server este API server é criado com este meta create server vem mesmo de um meta de um package HTTP simplesmente um servidor HTTP temos um config este config vem aqui das nossas API server options para além de muitas outras coisas que já viemos no código temos o API port onde este API server vai estar exposto nós vamos fazer pedidos a seguir a localhost 3.1 onde este API server vai estar exposto e depois damos uma lista de plugins estes endpoints vão estar todos dispostos pelo API server vamos ver enquanto eu conhecimento que o Rafael já nos está para passar a bocadinho se formos aqui as tensões este connector do IPFS está nas tensões e se formos ao open API vemos que temos aqui os diversos o path para estes endpoints todos vão ser 3 neste caso um get, um set e um has que os endpoints estão expostos pelo nosso API server esta pasta dos workshops tem aqui um readme o readme está bastante explicado bastante bem as coisas então se vocês vierem este momento temos que entrar nos examples do workshop e se fizermos aqui antes de corrermos este fichero do hello world ou então ter aqui o launch de jason e correr com o tap neste fichero e ele vai correr basicamente o que tiver aqui neste hello world pronto enquanto este corre rapidamente o que isto está a fazer no global por além do que está no slide estamos a inicializar aqui uma função main esta função main teria uma test ledger mas usando o ipfs uma rede ipfs através de um container nós fazemos o start desta rede e depois vamos fazer dar a configuração toda para o API server e quando corremos o API server com este plugin quando fizemos os request este plugin que está aqui recebe um dos argumentos que é este ipfs client auctions no qual inserimos o real da rede ipfs e portanto desta forma nós conseguimos fazer um request o API server o API server tem um conjunto de endpoints que é exposto pelo connector e o connector tem acesso a rede ipfs e portanto conseguimos interagir aqui com todas as coisas ao mesmo tempo pronto se eu abrir agora aqui um novo terminal aqui de lado eu vou tentar, por exemplo, adicionar um novo key value pair tenho aqui mais fácil usar aqui o readme se eu fizer aqui este curl para isto é um post aqui um, dois, três, quatro tem um value de x, y, z e este endpoints set object ele vai fazer que é exposto recebeu aqui o plugin o connector de ipfs recebeu e portanto se agora fizemos um get pelo mesmo aqui ele vai nos dar aqui o resultado atenção isto vai dar aqui uns caracteres que é um bocadinho estranhos porque isto é suposto estar tudo em base 64 nós não temos aqui a fazer estas conversões por razões simplesmente simplicidade e pois também temos aqui um request podemos verificar se o objeto existe ali ou não e vemos que o output para que um um request uma key que não existe no ipfs ele vai nos dar que está tudo a posse portanto, a partir de isto conseguimos se vocês tiverem o vosso plugin vocês podem ter-lo dentro de um API server expor o API server e fazer request a partir de de um cliente para este revidor o ok o Rafael já falou um bocadinho aqui da substrate test ledger basicamente nós podemos usar estas test ledgers para simular e para testar por exemplo o smart contract testar as aplicações sem preciso usarmos redes reais e portanto este é um dos casos o Rafael já falou um bocadinho sobre isto não vale a pena estar a ir novamente pois há aqui outro que é um consortium basicamente como é que podemos criar um consortium e com vários cactus nodes e basicamente é um exemplo muito básico sobre como é que podemos usar estas test ledgers do cactus este consortium também é usado aqui no supply change vamos ver um bocadinho a seguir mais em detalhe pronto então vamos ao supply change o supply change está na main branch não é preciso fazermos aqui nenhum tipo de de checkout nenhum brand qualquer se fizer em simplesmente o git pool ou o clone do projeto já tem estes exemplos e a forma de correr isto mais rápido é simplesmente vir aqui e correr o supply change e portanto ele vai demorar um bocadinho de tempo e ainda demora fazer algumas coisas mas aqui é a lógica do exemplo e eu não decorri o npm já agora convém com o npm com o npm e ele não sai de porque é normal ter um script já meta correr a seguir mas basicamente até há duas formas de correr isto aqui com o run and debug ou então com o readme tem algumas instruções dá para correr simplesmente com o docker por isso tem inversão já portanto podemos simplesmente correr isto com o docker e meter aqui a correr uma forma muito mais fácil e limpa de correr temos que usar aqui quando fizermos algum tipo de debug podemos usar os scripts que já estão feitos no package.json temos aqui um start example supply change isto vai fazer exatamente a mesma coisa e depois temos aqui outras formas para a parte do frontend para metermos aqui em live reload se quisermos estar a fazer development na parte do frontend e vermos o frontend sendo apodado a medida que vamos fazendo alterações qual é que é a lógica deste supply change no example nós temos como o rafael disse há pouco e havia aquela fotografia existem três ledgers aqui temos uma ledger do beso que é responsável pela parte do bambu portanto é como se fosse uma empresa que faz a produção do bambu depois temos outra ledger que é o do beso faz as tais são proteleras tantes através do bambu e depois temos outra ledger que é o fabrico que trata do shipment portanto é como se fosse uma empresa de distribuição de tantes que usa os dados da outra para fazer essa distribuição nós temos aqui o supply change business logic plugin basicamente isto é inclui a lógica toda de negócio deste exemplo portanto é principalmente este fichado que está aqui o que isto faz é basicamente expor os vários endpoints para as várias funcionalidades que oferecem portanto temos que ver inserir dados sobre o bambu listar-se dados sobre o bambu e isto vai parar a uma ledger neste caso aqui não estamos a fazer ainda distinções temos aqui para inserir estantes ou listar estantes e depois para a parte do shipment para fazer na parte do fabrico para fazer o envio e a parte da distribuição não tem estes endpoints que estão aqui estão todos definidos aqui nos web services vou abrir aqui um qualquer list de bambu este list de bambu tem aqui o endpoint dele a partir do momento em que vamos isto ocorrer se fizemos endpoints requestes e este endpoints então ele vai parar aqui este handler está aqui e se nós virmos o que ele vai fazer é fazer uma invocação a um smart contract está aqui o contrato o nome do contrato o nome isto tendo em conta que é o bambu vai ser uma rede do Bezo e portanto vamos dar as credenciais para acelerar a rede do Bezo temos de dar algum gas limit podemos ter aqui alguns parâmetros tendo em conta que isto é só um get não vamos pôr nada e portanto vamos agarrar neste nos dados que nos forem dados e depois vamos passar isto para um front-end para mostrar a lista dos records todos de bambu que tiver em vez de ser um get se for um insert temos aqui um insert na lista de shipment, nesta é no fábrica tentamos fazer também uma transação grande transaction request e este request tem aqui a sign in credential o channel name o contract name os argumentos todos que precisam para fazer uma transação num certo smart contract neste caso na fábrica isto é um plugin todo tal como eu disse o plugin tem de ser temos por isto um bocado de node ou no IPI server e é isso que é feito aqui no back-end no back-end e isto acaba por ser uma muita coisa mas é muito repetitivo ou seja as coisas são muito parecidas umas com as outras majoritariamente temos aqui este start em que nós fazemos o start destas ledgers vamos ter aqui que tem bem desta outra classe de infraestrutura temos aqui a ledger do beso do corum e do fábrica são todas test ledgers a primeira coisa que fazemos é fazer o start é fazer o start destas ledgers simplesmente que quando fizemos o shutdown da aplicação estas ledgers vão ser paradas para não ficar aqui consumindo recursos vamos fazer já o deployment de smart contracts aqui nesta classe da infraestrutura temos um método que faz o deploy dos smart contracts para cada uma delas vamos fazer o deployment de smart contracts temos aqui por exemplo chamar o connector do beso eles já foram criados para fazer um deploy de um smart contract neste caso vai buscar aqui este repositório JSON que está aqui e portanto vocês podem girar os vossos próprios smart contracts girar o ABI o JSON com o code e depois fazer o deploy do smart contract numa rede do beso por exemplo voltando aqui atrás podemos criar aqui podemos e temos de criar contas portanto usamos de credenciais para interagir com as ledgers criamos aqui contas dummy com obviamente falso ether para conseguirmos fazer transações nestas ledgers beso qual é o que temos aqui credenciais para aceder às a rede do fábrica e depois aqui a parte onde começamos os API servers onde vamos expor os nossos handpoints temos por exemplo neste caso vamos ter três API servers um para a parte do core um outro para o beso e outro para o fábrica e se eu saltar aqui um bocadinho para baixo eu já volto ali acima por exemplo aqui este API server A que exporta um API server este API server vai estar porto 4.000 vai ser um servidor a 4.000 podemos dar aqui um servidor também para a parte da interface onde é que a interface vai estar frontendo onde é que vai estar exposto e os registries que o Rafael também já falou um bocadinho basicamente são listas de plugins que vão ser expostos por este momento e portanto neste caso temos aqui um registry que começa aqui tem um plugin consortium tem aqui a configuração para criar um consortium de entidades temos o nosso supply chain plugin portanto é aquele business logic plugin que eu estava a mostrar o código a pouco e um conector do beso isto quer dizer o que que os handpoints exportados pelo conector do beso pelo supply chain plugin e por este consortium plugin vão estar expostos e nós podemos chamar os handpoints destes plugins e portanto isto vai ser tudo repetido pois para o pro quorum fazemos exatamente a mesma coisa e para o fabrico temos exatamente o mesmo registry e aqui adicionamos o fabrico conector temos um beso, outro quorum e outro e outro fabrico e este eles estão a ser criados a partir deste método start node isto é a parte do consortium este start node basicamente vai fazer aquilo que aquele hello world tinha tem um bocadinho mais de configurações pois antes não usávamos tanto temos aqui a utilização de protocol de autorização usejwt json write tokens e portanto criamos um API server a mesma forma que fazíamos antes mas ficará com um bocadinho mais com mais uns posinhos que acaba a ser um exemplo um bocadinho mais mais complexo para que acaba a ser aqui um bocadinho como é que o back-end desta da aplicação funciona eu não vou pôr aqui o front-end a funcionar simplesmente porque estou ocorrendo de uma VM e há aqui uns problemas de ter o browser deste lado mas vocês podem experimentar em este dos exemplos que normalmente se fala mais quando se fala do cacti e podem facilmente experimentar através daqueles através deste que eu tinha dito deste readme que seja através do docker seja através do run and debug é muito fácil meter a aplicação ocorrer e pois podem meter se meterem aqui através do run and debug podem pôr os breakpoints no código e ver como é que as coisas estão em interagem umas com as outras é bastante interessante se fizerem desta forma vamos então ao próximo exemplo que também ainda não está no main branch do cactus e agora vou passar aqui para a outra apresentação pronto, este exemplo que eu vou falar agora é usar um plugin que se chama odap o Rafael também falou um bocadinho disto no início odap ou satp como é o nome agora que se chama secure asset transfer protocol então é um plugin deste protocol no cactus e podemos usar para fazer transferências de assets eu vou-vos apresentar aqui um exemplo que é fazer uma bridge de central bank digital currency com esta com esta com este plugin pronto, então o que é este odap ou satp como estava a dizer é um protocol de transferência de assets entre networks a parte boa deste protocol é que vai ser trabalhado um objetivo de standardizar o cross chain communication tanto existem muitos protocolos neste momento e é difícil haver um só protocolo que faz aqui o enable da interoperabilidade entre múltiplas networks e portanto é isso que estamos aqui a tentar fazer de um protocol fazer transferências de assets de uma forma imediata, vimos assim pronto, de qual é a arquitetura desta protocolo então usar gateways os gateways podem ler e escrever das networks, dos blockchains em que estão deployed e depois correm entre elas um protocolo que é o odap ou satp que vai fazer transferências de assets e portanto nós enquanto rede confiamos nestas gateways para fazerem estas transferências de umas coisas outras então estas gateways são responsáveis por estas pelas ações e por correndo de uma forma confiável nas redes em que estão inseridas pronto, isto é um bocadinho o diagrama de sequência tem muitas mensagens que a parte mais relevante é quando as gateways interagem com as ledgers não temos aqui neste caso um fabrico uma rede fabrico à esquerda, uma rede beso à direita se fizermos aqui o protocolo em si as três operações mais críticas mais importantes é fazermos o loco do asset que nós queremos transferir na blockchain da origem pois eventualmente fazemos um delete e uma criação de uma representação deste asset na blockchain de destino no final tem aqui uma três fases, uma fase primeira de agreement entre as duas gateways pois temos uma fase que é preparar e certificar que o asset está locto em uma das blockchains e depois fazemos aqui os commits que é eliminar de um lado e criar do outro e está aqui o link para basicamente os diagramas isto obviamente é um working progress muitas vezes isto vai mudando assim de semana para semana e portanto as figuras mais atualizadas pronto, onde é que isto este plug-in sincera aqui no Cactus na packages na pasta packages aqui este Cactus plug-in no da pernos basicamente lá dentro temos todo o source code para construirmos uma gateway e a forma como instanciamos uma é há uma classe que é o plug-in no da gateway que não pode ser instanciado e diretamente porque é uma abstract class isto implementa basicamente os todos endpoints que tem a ver com a lógica do ODP ou do SATP mas não implementa coisas específicas de ledgers e isso é feito por instanciações específicas que nós temos temos para o fabrico temos para o Bezzo mas eventualmente podemos ter mais e vocês se quiserem contribuir para o projeto é uma boa forma é implementar uma gateway para outra ledger desenvolver smart contracts e desenvolver um bocadinho a lógica para fazer a interação com essas smart contracts locos, creatos, ledgers etc pronto um exemplo de como instanciar uma fabrico gateway temos aqui o Deltiaid basicamente é dizer a compatibilidade eu sou fabrico com uma gateway fabric e posso dizer que só consigo interagir com gateways que estão ligadas a uma rede Bezzo depois temos o IPFS path basicamente para fazer os storage de logs não é muito relevante aqui temos configurações como fabrico qual é que é a rede do fabrico qual é que é sign credentials channel name contract name e depois temos aqui duas classes que podem ser estendidas ou não se não estendermos a sua default mas podem ser estendidas tendo em conta use case podem ver preficações que têm de ser feitas em use case específicos como vamos ver um exemplo baseado em cdc é preciso fazer diferentes checks de um exemplo baseado em supply chain pronto, então o exemplo é de tirar o código daqui a bocadinho deste use case é basicamente termos uma fabric ledger à esquerda e a rede e temos uma rede Bezzo à direita que é quase que uma retail business ledger e portanto expõem serviços aos clientes e os clientes querem usufruir dos serviços e têm de pagar de alguma forma e portanto tem de haver aqui uma ligação entre a rede que tem o dinheiro e a rede que oferece serviços foi um projeto feito no hyper ledger mentorships deste ano deste verão e se quiserem ver um bocadinho mais em detalhe a arquitetura da central bank digital currency e do prototype podem ver aqui esta apresentação do meu mentor Imre no hyper ledger global forum em setembro então como é que nós fazemos aqui o enabled interoperabilidade entre estas duas networks até com o cacti, com uma bridge para cada lado e portanto nós criámos aqui dois smart contracts em cada lado temos aqui este cbdc chaincode isto é basicamente a lógica do smart contract ou a lógica do cbdc num smart contract como se fosse um iar c20 smart contract e depois temos um asset reference chaincode basicamente um um objeto, este asset reference que faz o wrap de vários cbdc e portanto quando Alice com o fabrica ID quer fazer o escro de 50 cbdc quando quer fazer o bridge destes 50 cbdc primeiro tem de fazer um lock então ela não pode ficar com 50 de um lado 50 do outro então você cai este escro aqui este é o que vai criar um asset reference que representa este 50 cbdc ela vai buscar o ID deste asset reference e falar com a gateway que é para iniciar o what up para o outro lado ou setp e portanto como vimos este protocol inclui fazer o lock no lado fazer o delete e depois fazer a criação da representação deste asset na rede do beso e portanto aqui deste lado vão saber o que este asset reference de contract consegue perceber o que é este objeto vai desconstruir vai fazer um mint de 50 cbdc para o cbdc smart contract e basicamente isto vai ser feito para o atirim o adress de Alice nesta segunda blockchain e portanto Alice tem neste momento 50 cbdc que pode usar na retail businesses ledgers portanto a forma como isto é feito no cactus ou implementado temos um lado ligado ao fabric temos outro lado ligado ao beso que é a única coisa que difere os dois lados neste connector um é para um lado e outro é para uma ledger ou outro e a parte de baixo é um bocadinho para login, IPFS e a base data temos os logs e a parte mais interessante para perceber é termos um API server e vamos meter lá dentro os connectors que temos portanto só olhamos um bocadinho para o Codi e eu posso meter aqui o link para o repositor e para isto é para ainda específico podem ver isto é um public request aberto que ainda não foi morto aqui um fechero que é o Cdc bridging app que é muito parecido com o supply chain que é o da app Codi parecido no sentido de criar estes API servers nós damos um servidor HTTP e um registry um plugin registry que tem todos os plugins que vão ser necessários para aquele API server para o lado esquerdo do fábrica temos o fábrica connector temos uma fábrica gateway e o plugin para o IPFS e no lado do server temos exatamente o mesmo e neste é para o fábrica temos uma base uma base o gate uma base o connector e outra vez um connector para o IPFS mas para o API server para isto estar feito nós temos os nosso API servers a correr e vamos basicamente fazer o deploy dos smart contracts portanto temos tal como eu disse o Cdc smart contract de asset reference os dois chain codes aqui do lado do fábrica pois o base está tudo aqui no mesmo método e pronto vai estar tudo deploy de nas networks do decorrer pronto vocês podem testar é muito simples testar este exemplo que o front end está numa docker image ainda não vai estar aqui no main branch por enquanto do cacti mas o back end novamente é fazer o npm run start do exemplo ou então novamente fazer com o template launch chasing que estiver lá nesse repositório pois também vai aparecer aqui uma opção em baixo de eu posso ir lá rápido está aqui aqui mais um exemplo mais uma configuração e portanto pode se também correr aqui e correr em debug como tínhamos feito aqui com os outros exemplos se aqui era aqui agora já não aparece pode se ocorrer isto e eventualmente ele vai dar se se não partir como partiu algo para alguma razão ele não tinha que as dependências instaladas pronto esta interface basicamente este exemplo todo vai dar uma coisa deste gender então é engraçado ver aqui os valores aí do lado ao outro e ver aqui o bridge a funcionar então vamos fazer o mint tokens do lado, fazer o escrow para criar os asset references e ver os a serem criados ver a lista da asset references e depois temos que fazer o bridge out que é basicamente de fabrico pro beso e depois quando estiver aqui fazer o precisamente o sentido contrário que é o bridge back pronto está aqui um vídeo até de está aqui neste care code um vídeo de interagir com este frontend com esta aplicação e ver as coisas aqui a funcionar pronto eu posso mostrar aqui um bocadinho mais o código da aplicação que basicamente acaba a aparecer um bocadinho vou mostrar aqui os pontos mais mais mais importantes nós temos aqui a nossa aplicação é muito similhante aqui a parte da criação dos dos ebi servers e os registry mas aqui temos o keychain para a questão de chaves e os nossos plugins todos depois este start não acaba a aparecer o mesmo obviamente de acordo com aquilo que é o sito do frontend neste caso que acaba a aparecer feito de uma forma um bocadinho diferente do que o supply chain, exemplo mas aqui a parte que pode ser mais interessante é esta tem-se fazer aqui esta extensão do audap portanto é quase que estender uma gateway que já existe e criar uma implementação de uma gateway que interashe os que aí embaixo têm aqui os como é que interashe jimps fazer o delete de um asset no smart contract o lock do asset unlock para o caso de haver um rollback exatamente criar um asset de rollback etc, pronto acaba a aparecer um bocadinho o código de este exemplo pronto, passa aqui a palavra o rafael outra vez e vamos para aqui se o rafael está aqui ou sim estou obrigado André por nos guiar através dos vários exemplos acho que foi bastante escorcedor portanto se alguém tiver dúvidas podem sempre rever a gravação do workshop e buscar a vossa memória vamos agora para a parte final do workshop em que falamos do futuro dos pontos futuros do projeto próximo slide portanto nós temos um diagrama da arquitetura para a primeira versão unidamente o cactus agora com o merge do cacti vamos introduzir não só a arquitetura os diagramas da arquitetura técnica finais mas também finalizar um merge destas code bases portanto a versão 2 terá analisação completa do merge próximo item portanto vamos também trabalhar um bocado na parte da identidade através de diversos plugins foi perguntado temos um connetor proengue e provavelmente estar nos planos para dar suporte a vários tipos de identidade nomeadamente de ids suporte ao core da versão 5 portanto com alguns dos algumas mirias nas suas componentes documentação vamos adicionar mais exemplos e basicamente fazer um update generalizado a toda a documentação e também o primeiro deployment público em relação a performance vamos vamos fazer benchmarks com resultados públicos para testar performance não só dos connectors mas das componentes core portanto se quiserem contribuir para o código as toleirões e instruções estão bastante teiadas e ensinam-vos também o slow de projetos open source o nosso ponto principal de contacto é o discord de channel cacti cactus e tem informações gerais no nosso week o próximo slide também de salientar que este projeto é bastante útil para a investigação e interoperabilidade não só de blockchain mas de projetos que sejam heterogéneos portanto há vários papers que nós escrevemos neste mesmo tema e inclusivamente diversos estesos na estrada portanto se forem alunos e estiverem interessados em escrever paper para as academias contactem-nos próximo slide temos aqui mais papers também feitos pela malta previamente chamada weaver e outros alucinados pronto, é finalmente agradecer à mônica que afusamente não conseguiu estar presente mas que fez grande parte do trabalho para pôr este workshop de pé ao peter que é um dos maintainers do projecto e que também nos ajudou na parte técnica do workshop Tua Binaf contribuiu para uma versão inicial e à comunidade hyper ledger em especial todos os membros da comunidade que suportaram a criação o desenvolvimento a apresentação deste workshop em português também agradecer ao David Basel que ajudou a organizar o workshop pronto, finalmente isto encerra workshops para que tenham gostado e aprendido coisas novas connosco gostaria de saber se alguém tem algo na pergunta prenserrante muito obrigado Bruno quando podem escrever vossas lutas por sete ou usar através de microfones fiquem à vontade de qualquer maneira nós estaremos no discord para um futuro contacto ok visto que não há nenhuma pergunta gostaria de encerrar o workshop eu acho que estamos terminados muito obrigado Rafael e muito obrigado a todo o time por colocar este ótimo workshop muito agradecer a todos os atendidos eu vou enviar uma gravação no e-mail e nós vamos colocar links para a apresentação ou na descrição do vídeo do YouTube eu também inclui o link do YouTube no chat, mas o link do YouTube vai estar no e-mail também, mas muito obrigado a todos muito obrigado Rafael, isso foi ótimo obrigado a todos