Documentação e arquivos de configuração para participação no Piloto do Real Digital
Este repositório contém as informações necessárias para a participação no piloto do Real Digital. A documentação será complementada conforme o feedback dos participantes.
Os eventos SwapStarted e SwapExecuted da ABI SwapTwoSteps não contém o parâmetro proposalId conforme especificado na documentação.
Ao revisar os documentos relacionados à implementação do contrato para o Real Tokenizado, notei que, embora sejam mencionados os termos "DVt" e "MEt", não está claro como eles são distintos um do outro no contexto do contrato. Considerando que ambos são ativos com comportamentos potencialmente diferentes, essa distinção é crucial.
Estou curioso sobre o papel do ponto de "Reserva" e como ele se relaciona com esses dois termos. Adicionalmente, estou avaliando a possibilidade de implementar um ratio no contrato que conecte o depósito compulsório à quantidade de Real Tokenizado emitido pela instituição. Seria possível esclarecer estas questões?
Estou realizando alguns testes com contratos que implementam a abi divulgada em um cluster besu configurado conforme o config.toml e por curiosidade comecei a testar cenários de falha e notei que o revert-reason sempre vem vázio, dando uma olhada na documentação do besu vi que isso precisa ser ativo como podemos ver aqui, porém no config.toml do repositório não existe esse parâmetro, quando houverem regras de negócio não atendidas como por exemplo o cliente A não tem saldo suficiente para transferir para o cliente B, como poderemos consultar sem o reason ? Haverá algum evento com essa informação ?
Prezado(a)s,
Gostaria de consultar se há canais de comunicação para receber dados de vulnerabilidades de forma segura, de preferência com criptografia ponta a ponta.
Obrigado,
Pedro Magalhães
Os contratos SwapOneStep e SwapTwoSteps não possuem as roles apropriadas (BURN , MINT, MOVE) para efetuar as transações necessárias nos tokens dos participantes e verificamos que as Roles só podem ser concedidas pelo BC.
Gostaria de entender a necessidade de usar um blockchain privado baseado em Proof of Authority (PoA)?
PoA centraliza a validação, sendo totalmente contra a proposta do blockchain que seria a descentralização.
Além dos riscos de censura, vulnerabilidades e falta de transparência.
E a principal pergunta, que tipo de problema reais motivaram a criação desse projeto? Talvez isso ajude um pouco a compreender a escolha de usar Proof of Authority.
A documentação diz haver uma função mapping (swapProposals) de propostas de SwapTwoSteps. Porém essa função não existe na ABI.
Documentação:
https://github.com/bacen/pilotord-kit-onboarding/blob/main/SwapTwoSteps.md#swapproposals
Qual vai ser a solução que o Banco Central vai utilizar para garantir a transparência e a confiabilidade da rede e a ao mesmo tempo a privacidade dos usuários?
Originally posted by @sandrogomes94 in #14 (comment)
Olá.
Entendi que o contrato AddressDiscovery será usado para se obter os endereços dos contratos inteligentes, porém fiquei com dúvidas em relação à obtenção do endereço do contrato RealTokenizado, pois pela descrição do construtor do RealTokenizado e pelas lives/workshops do BACEN que já foram ao ar até então subentende-se que cada participante terá a sua própria instância do contrato RealTokenizado, pois no construtor deste alguns dos parâmetros serão a identificação e o cnpj do participante.
No AddressDiscovery existe um mapping de: nome do contrato => endereço; é uma relação de 1 x 1. Dado que o mapping addressDiscovery é somente uma variável e não uma função, e que ao ser definido como public é criado um getter simples para essa variável, entendo que não existe nenhuma forma de estruturar uma condição de "se o participante X estiver interagindo, retorne o endereço Y". Como então cada participante conseguirá consultar o endereço da sua própria instância do contrato RealTokenizado se o mapping só permite um 'valor' para cada 'chave' e todos os participantes consultarão o mesmo mapping?
Dúvida à parte: eu iria abrir um tópico em "Discussions" mas reparei que nada lá foi respondido desde então. O BACEN vai responder somente através de issues?
A documentação que descreve o papel de congelamento para o real digital sugere a utilização do congelamento de saldo para o swap de dois passos. No entanto, ao congelar o saldo do cliente da instituição pagadora, a instituição recebedora teria que descongelar o saldo da outra instituição para executar o swap, o que é inviável porque a outra instituição não deveria ter esta autorização.
Essa sugestão está correta?
Prezado(a)s,
Sou desenvolvedor Full Stack a 10 anos e venho trabalhando com Solidity nos últimos 4 anos.
Gostaria de perguntar se posso realizar PR, de forma voluntária, com novos teste unitários ou sugerir melhorias em termos de segurança, desenvolvimento e documentação.
Vi que na topologia da rede está indicado a logo do AngularJS no ambiente offchain conectando ao RPC. Gostaria de entender o que significa?
O ABI (TPFt.json) ainda não foi disponibilizado, apesar do contrato já ter sido deployado na rede e as interfaces terem sido disponibilizadas. Será disponibilizado em breve?
O Real Digital e o Real Tokenizado têm valores definidos com 2 casas decimais como informado em smartcontracts.md. Entretanto os documentos ITPFtOperation1002.md e ITPFtOperation1052.md mencionam o preço unitário do TPFt com 8 casas decimais.
Olá equipe de desenvolvimento,
Estou revisando a documentação do contrato "ITPFt" no projeto e estou interessado em entender melhor sua função e como ele se encaixa no ecossistema geral do projeto. A documentação fornece detalhes sobre os métodos e eventos do contrato, mas não especifica se este é um contrato independente ou uma interface.
Gostaria de solicitar mais informações sobre o contrato "ITPFt" para esclarecer os seguintes pontos:
Este contrato "ITPFt" é uma interface ou um contrato independente? Se for uma interface, quais contratos implementam essa interface?
Qual é o propósito principal do "ITPFt" dentro do sistema? Como ele se relaciona com outros contratos ou partes do sistema?
Qualquer informação adicional que você possa fornecer sobre o contrato "ITPFt" seria apreciada.
Obrigado pela ajuda!
Atenciosamente,
Cristiano
De acordo com as configurações contidas no config.toml, não está sendo usado o permissionamento de transações na rede. Ele será usado posteriormente, ou de fato não será utilizado?
Com o permissionamento de transações configurado, seria possível gerenciar quem pode transacionar na rede e, até mesmo, quem pode fazer deploy na rede. Acredito ser uma ferramenta poderosa para condicionar as transações a um conjunto de regras. Como quem pode enviar, quem pode receber, até qual valor, até qual quantidade de gas etc.
Está previsto algo desse tipo na rede?
Olá,
Nossa carteira tem saldo suficiente para transferir Real Digital.
Foram realizados os depósitos para o contrato Escrow (os dois commitments não gastos necessários para a transferência).
Na hora de fazer a chamada de transferência tenho o seguinte erro:
Os parâmetros do nó Besu já foram configurados e o nó foi reiniciado, porém, o erro persiste.
Alguém pode ajudar?
Obrigada.
De acordo com a documentação do Besu, os static nodes são um conjunto de nós confiáveis e estão isentos dos limites máximos de conexão remota.
Ao se tratar de uma rede permissionada, como é o caso do DREX, em que os nós são conhecidos e permissionados onchain, não seria o caso de utilizar static nodes na conexão dos nós?
O mecanismo de discovery, utilizado atualmente, é feito via protocolo udp, o que fragiliza uma conexão efetiva com os outros nós pela natureza desse protocolo. Além disso, a conexão dos nós via static nodes minimiza a dúvida da origem de um eventual problema de conexão entre os peers - se o problema é no nível de firewall ou no nível do Besu - uma vez que o Besu tenta manter conexões com os static nodes iniciando periodicamente uma conexão com qualquer static node desconectado.
Para cada novo nó ingressante na rede, seria necessário executar o comando admin_addPeer (para adicionar um nó estático em tempo de execução) e também adicionar o novo nó em um arquivo .json que já contenha os outros static nodes listados (a fim de que mesmo que um nó reinicie, o besu faça a tentativa de conexão, pois o comando admin_addPeer não persiste após o reinício de um nó).
É possível disponibilizar as ABIs dos contratos CBDCAccessControl e AddressDiscovery?
Obrigado.
Hello,
the constructor ABI
{
"inputs": [
{
"internalType": "contract RealDigital",
"name": "token",
"type": "address"
}
],
"stateMutability": "nonpayable",
"type": "constructor"
}does not match the documentation for RealDigitalDefaultAccount.
Which one is correct and what's the intent of passing RealDigital to RealDigitalDefaultAccount?
Haverá algum tipo de enforcement no permissionamento de nós da rede?
Caso um nó esteja listado no smart contract de permissionamento de nós mas não habilite o permissionamento de nó no config.toml, este nó pode se conectar com um outro fora da lista de permissionamento e, assim, permitir que nós despermissionados participem da rede.
Desse modo, será desenvolvido algum tipo de reforço para o permissionamento ou as configurações de firewall e permissionamento são consideradas suficientes? #29
De acordo com a documentação sobre os contratos de swap é sugerido a utilização do método approve (tanto do real tokenizado quanto do real digital) antes da chamada do método que executa o swap, no entanto, pela especificação do método approve e na vulnerabilidade que esse método apresenta (também encontrada aqui), o método increaseAllowance parece ser o mais adequado para esse fim, uma vez que o approve redefine o valor permitido a ser gasto por outro endereço, enquanto o increaseAllowance apenas incrementa o allowance, o que (de certa forma) isola o respectivo allowance para uma determinada transação.
Utilizar o approve poderia invalidar a execução de transações simultâneas, não só de swap, mas de outras transações que envolvam o allowance.
Pessoal, parabéns pelo lançamento!
Serão disponibilizados os endereços e o código fonte dos contratos para o público?
Qual explorador de blocos será usado?
De acordo com a documentação do real digital sobre o método _beforeTokenTransfer, toda transação de transferência de tokens passa por uma checagem de acesso do remetente e destinatário que verifica se ambos estão autorizados a receber/enviar tokens.
Dessa forma, toda autoridade de um contrato de real tokenizado pode impedir o uso do SwapTwoStepsReserve quando desabilitar o endereço do contrato de receber tokens com o método disableAccount do qual a autoridade possui permissão para executar.
Esse é de fato o comportamento esperado?
Investigando as ABIs dos contratos de Swap (SwapOneStep e SwapTwoSteps), notei que os eventos de SwapExecuted não têm parâmetros indexados:
{ "anonymous": false, "inputs": [ { "indexed": false, "internalType": "uint256", "name": "senderNumber", "type": "uint256" }, { "indexed": false, "internalType": "uint256", "name": "receiverNumber", "type": "uint256" }, { "indexed": false, "internalType": "address", "name": "sender", "type": "address" }, { "indexed": false, "internalType": "address", "name": "receiver", "type": "address" }, { "indexed": false, "internalType": "uint256", "name": "amount", "type": "uint256" } ], "name": "SwapExecuted", "type": "event" }
Considerando as práticas comuns de eventos indexados, e considerando que os participantes do piloto (provavelmente) irão ter alguma espécie de "listener" para replicar os eventos de transferência;swap em um banco de dados offchain, penso que seria interessante indexar os parâmetros dos eventos de Swap (e.g: indexar o senderNumber e o receiverNumber para que o participante consiga criar um filtro e captar somente os eventos de transferência onde ele é o pagador ou recebedor)
A nomenclatura dos métodos "trade", na interface ITPFtOperation1052, gera problemas em diversas bibliotecas, apesar da assinatura diferente.
Sugiro a alteração da nomenclatura para tradeByAdresses e tradeByCNPJ8.
Grato
Prezado(a),
Analisando essa notícia, https://valor.globo.com/financas/noticia/2023/07/17/itau-instala-o-primeiro-no-da-rede-do-real-digital.ghtml
Gostaria de consultar, em qual camada foi instalado o nó da rede do Banco Itaú, considerando que existe uma topologia atual fornecido dentro das documentações, onde é demonstrado somente os nodes e validadores do Bacen e outras instituições públicas.
Assim como gostaria de consultar esse desenho atual da arquitetura em anexo, pode ser considerando uma fonte de estudos do arranjo do Real Digital, e em qual nó o Itaú está incluído.
O primeiro input para a function addDefaultAccount do ABI RealDigitalDefaultAccount.json está especificando o name como:
"name": "cnpj8",Já a function defaultAccount não especifica qual é o name de seu input:
{
"inputs": [
{
"internalType": "uint256",
"name": "",
"type": "uint256"
}
],
"name": "defaultAccount",
...
},Sugestão: se o input esperado para defaultAccount realmente for um cnpj8, sugiro especificá-lo para dar clareza ao que se espera como entrada para execução da function.
Exchanges vão poder listar o Real Digital e permitir o câmbio para o USDT?
Bitcointoyou.com
Eu não entendi muito bem se haverá algum tipo de auditoria sobre as configurações do nó do ledger obrigando seguir as configurações do config.toml do repositório ou se há configurações que serão opcionais para as instituições, por exemplo:
metrics-enabled=false
graphql-http-enabled=false
rpc-ws-enabled=false
Essas configurações realmente precisam estar desabilitadas? Ou isso é algo que a instituição que subiu o nó irá decidir?
O arquivo de imagem da topologia está quebrado, não está sendo possível sua vizualização.
Obrigado
O evento ExpiredProposal é emitido na chamada de qual método dos contratos de SwapTwoSteps?
Existe a previsão de quando e como serão disponibilizados os endereços dos contratos para os participantes do piloto?
Pelo que se observa no código, os endereços que na prática seriam endereços reais dos contratos, estão sendo passados direto no código, o que pode acarretar em vulnerabilidade. Melhor prática seria isolar em variáveis de ambiente ou outro mecanismo para armazenar esses endereços a parte, protegendo as informações.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.