follow us on twitter . like us on facebook . follow us on instagram . subscribe to our youtube channel . announcements on telegram channel . ask urgent question ONLY . Subscribe to our reddit . Altcoins Talks Shop Shop


This is an Ad. Advertised sites are not endorsement by our Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise Here Ads bidding Bidding Open

Author Topic: RadixDLT, O Protocolo de Finanças Descentralizadas (revisão completa)  (Read 11524 times)

Offline rezanahvi

  • Full Member
  • *
  • Activity: 224
  • points:
    17257
  • Karma: 0
  • Decentralized Gaming & NFT Ecosystem
  • Trade Count: (0)
  • Referrals: 0
  • Last Active: February 06, 2024, 08:00:22 AM
    • View Profile

  • Total Badges: 15
    Badges: (View All)
    Fifth year Anniversary Fourth year Anniversary 10 Posts
RadixDLT, O Protocolo de Finanças Descentralizadas
(revisão completa)


Introdução
Radix é uma plataforma de alto rendimento para construir e distribuir aplicativos descentralizados.
Em pesquisa e desenvolvimento desde 2011, Radix DLT é o primeiro protocolo de ledger distribuído infinitamente escalável para sistemas sem confiança. É um banco de dados distribuído eventualmente consistente, com ordenação absoluta de eventos relacionados e detecção de n-1 falha. Ele é projetado especificamente para facilidade de uso e execução em dispositivos com recursos restritos, ajudando a impulsionar a adoção em massa e para uso na Internet das Coisas (IoT).
A plataforma Radix permitirá que os desenvolvedores criem, distribuam e gerenciem aplicativos distribuídos altamente escaláveis, eficientes e seguros para redes públicas e privadas.
A Rede Pública Radix é um computador modular, de uso geral e global para aplicativos descentralizados que permite transações econômicas e escalonáveis em velocidades incríveis com finalidade quase instantânea.

Tecnologia
O Radix oferece uma nova arquitetura de razão distribuída para aplicativos descentralizados que é fragmentada para escalar de uma forma linear eficiente e ilimitada combinada com um algoritmo de consenso seguro chamado 'Tempo'.

Radix Tempo
O Tempo Ledger consiste em três componentes fundamentais:
• Um cluster de nós em rede
• Um banco de dados de razão global distribuído entre os nós
• Um algoritmo para gerar um registro criptograficamente seguro de eventos ordenados temporalmente.
Uma instância de Tempo é chamada de Universo e qualquer evento dentro de um Universo, como uma mensagem ou transação, é representado por um objeto chamado Atom.
Todos os átomos contêm pelo menos um destino de terminal, representado por um endereço de terminal. Os endereços de terminal são derivados de uma identidade, como a chave pública de um usuário, e são usados para rotear eventos pela rede.
Os átomos geralmente assumem a forma de átomos de carga útil ou átomos de transferência. Um exemplo de Payload Atom é uma comunicação enviada a uma ou mais partes, como um e-mail ou uma mensagem instantânea. Os átomos de transferência são usados para transferir a propriedade de um item, como moeda, para outra parte.
Os átomos também podem conter outros átomos, bem como vários outros dados, dependendo de sua finalidade. Esses dados extras podem incluir destinos condicionais, proprietários, participantes, associações e metadados do aplicativo. Variantes exóticas do Atom podem ser criadas para fins de aplicação específicos, se necessário.

Figura 1: Tipos Atom padrão e estrutura básica

Os clientes podem criar e enviar átomos à rede por meio de qualquer nó ao qual estejam conectados. Um Atom enviado é então processado pela rede e, se válido, uma Prova Temporal é construída e associada a esse Atom daquele ponto em diante.
O Tempo depende muito da consistência eventual para obter uma ordenação total dos eventos.

Arquitetura Ledger
O ledger Tempo é um banco de dados distribuído que armazena todos os átomos que existem em um universo. Ele é projetado para ser horizontalmente escalável, oferece suporte a dados semiestruturados e pode atualizar entradas.
Uma instância do razão local operando em um nó pode ser configurada para armazenar todo ou parte do razão global. Um subconjunto do razão global é conhecido como fragmento. O espaço total do shard é configurável por Universo, mas é imutável depois de implantado. Os nós podem ser reconfigurados para suportar qualquer subconjunto do espaço do shard, ajudando a garantir que o Universo possa lidar com grandes requisitos de carga sem exigir hardware caro para operar um nó. Isso permite que dispositivos IoT com desempenho restrito participem como cidadãos de primeira classe em um universo.
Sharding é um recurso de design fundamental do Radix, o que implica uma abordagem robusta para garantir que os átomos estejam nos fragmentos corretos e um método eficiente para determinar quais nós reterão cópias de quais átomos.
Considerando que todos os átomos devem ter pelo menos um ponto de extremidade em seus destinos, podemos derivar um ID de fragmento usando o destino, truncado para as dimensões do espaço do fragmento por meio de um operador de módulo. Alguns Atoms, como Transfer Atoms, podem ter vários destinos e, portanto, estarão presentes em vários shards.
Isso ocorre por design, como um Atom presente em vários shards aumenta a redundância e a disponibilidade desse Atom. Um outro benefício é que qualquer Atom que executa uma transferência entre fragmentos está presente nos fragmentos do proprietário anterior e do novo proprietário. Isso, em parte, elimina a necessidade de um estado global e mitiga quaisquer operações caras de verificação de estado entre fragmentos necessárias para evitar “gastos duplos”.

Transferências
Enquanto os átomos de carga útil são relativamente simples, compostos de alguns dados arbitrários, destinos e uma assinatura, os átomos de transferência são mais complexos.
Um item de propriedade é representado por um Consumível. A propriedade é definida como uma sequência de consumíveis, que fornece um histórico auditável dos proprietários ao longo do tempo. Os consumíveis são uma subclasse do Atom.
Para transferir a propriedade de um Item (α) contido no Atom (αn) para Bob, Alice cria um Consumidor (αX), que faz referência ao Consumível (αn) que a especifica como a atual proprietária e a assina com sua identidade. Os consumidores também são uma subclasse do Atom e identificam um Consumível que deve ser“consumido”.
Ela também cria um novo Consumível (αX), que contém o item (α) sendo transferido, junto com a identidade do novo proprietário: Bob. O consumidor e o consumível são empacotados em um novo Atom (αX) e enviado à rede para verificação.

Figura 2: transferência de propriedade

Qualquer nó que recebe o Atom de Alice (αX) agora pode validar trivialmente que Alice é de fato a atual proprietária do Item (α) Isso é realizado através da validação da assinatura do Consumidor enviado (αX) contra as informações do proprietário presentes no último consumível para o Item (α) realizada no nó's livro-razão local. Se a assinatura for validada com sucesso, Alice deve ser a proprietária atual. A transferência será executada e Bob se tornará o novo proprietário.
Algumas operações de transferência podem exigir que o Item (α) não seja transferido em sua totalidade, como a moeda. Os consumíveis podem ser configurados para permitir transferências parciais de um item, se a especificação do item permitir. Nesse caso, Alice criaria dois consumíveis, um para Bob para o princípio e outro para ela mesma para o restante. Da mesma forma, vários Consumidores podem ser usados para fazer referência a muitos Consumíveis de propriedade de Alice e transferi-los todos para Bob em uma execução, garantindo assim a atomicidade e reduzindo a carga da rede.

Entrega de informação
Para garantir a entrega rápida de eventos a todos os nós em um fragmento, o Tempo emprega um protocolo Gossip para comunicar informações pela rede. Os protocolos de gossip provaram ser um meio eficiente e confiável de alcançar a propagação em massa de informações em uma rede ponto a ponto.
Os nós transmitem informações sobre sua configuração, como um conjunto de fragmentos para os quais desejam receber eventos e informações de estado, e quaisquer serviços de rede que possam oferecer (como retransmissão e descoberta), permitindo uma maior otimização da entrega de informações. Eles também podem transmitir metadados sobre os outros pares aos quais estão conectados, auxiliando ainda mais no roteamento de informações e eventos.
Os nós dentro da rede adotam uma abordagem de “melhor esforço” para manter seus livros-razão locais atualizados por meio de sincronização ativa e protocolos de fofoca. Ao receber um Atom por qualquer um desses meios, um nó executará a validação do Atom em relação ao seu razão local. Se uma discrepância comprovável for descoberta, um nó pode comunicar essa informação a seus nós vizinhos, permitindo-lhes agir e resolver a discrepância.
Embora confiável, essa abordagem sem dúvida levará a ocasiões em que eventos são perdidos e o estado de um item pode estar incorreto em algumas instâncias do razão local. Para resolver essas inconsistências, os nós contam com anomalias de histórico causais detectáveis acionadas por eventos. Eles podem então consultar outros nós para obter informações ausentes e obter consistência eventual com o resto da rede em relação a um evento e seu estado subsequente.

Disponibilidade do evento
Para que os átomos sejam validados corretamente, eles precisam ser roteados para os nós que contêm os fragmentos associados, permitindo que o histórico causal de quaisquer Consumíveis, estado e outras informações sejam verificados.
Os destinos de terminal fornecem as informações de roteamento necessárias para garantir que os átomos sejam recebidos pelos nós apropriados por meio da camada de comunicação de fofoca.
Considere o exemplo de Alice transferindo o Item (α) para Bob. Alice incluiu seu destino final, que indica que ela está transferindo do Shard (1), e incluiu o destino final de Bob, que indica que ela está transferindo para o Shard (3). Nós que armazenam fragmentos (1∥3) precisa estar ciente do evento de; Alice's gastar; Prumo'recibo s; e do estado do item (α) em cada fragmento. Após o evento, os nós que armazenam o Fragmento (1) não precisam mais estar cientes de quaisquer mudanças futuras no estado do Item (α) (a menos que seja enviado novamente para o Fragmento (1)). A responsabilidade do estado do item (α) foi transferida para todos os nós que armazenam o Shard (3). Se Bob então passar o Item (α) para um proprietário em outro fragmento, a responsabilidade de manter o estado do Item (α) será novamente alterada.

Figura 3: Fofoca de Fragmentos de segmentação do Atom α X (1, 3)

O processamento apenas de eventos que afetam o estado dentro de um subconjunto do nó do razão global e a mudança de responsabilidade da manutenção do estado, reduz bastante a sobrecarga total de processamento do estado. Esta é a chave para o desempenho de ajuste de escala do Tempo.

Relógios lógicos
A base do consenso Tempo baseia-se em Logical Clocks, que são um meio simples de fornecer uma ordem relativa e parcial de eventos em um sistema distribuído.
Dentro do Tempo, todos os nós têm um relógio lógico local; um valor inteiro sempre crescente que representa o número de eventos testemunhados por aquele nó. Os nós incrementam seu relógio lógico local ao testemunhar um evento que não foi visto anteriormente. Ao armazenar um evento, o nó também armazena seu valor de relógio lógico atual com ele. Este registro pode então ser usado para ajudar a validar a ordem temporal de eventos anteriores, se necessário.
Somente o recebimento de um Atom que não tenha sido testemunhado anteriormente por aquele nó pode ser classificado como um “evento” para qualquer nó dentro do Tempo.

Provisionamento de prova temporal
Um universo é dividido em fragmentos, onde os nós não são obrigados a armazenar uma cópia completa do livro-razão global ou estado. No entanto, sem um algoritmo de consenso adequado que permite que os nós verifiquem as mudanças de estado nos fragmentos que eles mantêm, o “gasto duplo” seria um exercício trivial, em que um ator desonesto poderia gastar o mesmo item em dois fragmentos diferentes.
Provas temporais fornecem uma solução barata e resistente à violação para o problema acima. Antes que um evento possa ser apresentado a toda a rede para aceitação global, uma validação inicial do evento é realizada por um subconjunto de nós que, se bem-sucedido, resulta em: Uma Prova Temporal sendo construída e associada ao Atom, e uma ampla rede transmissão do Atom e sua Prova Temporal.
Usando a transferência de Alice de Item (α) para Bob como exemplo, o processo começa com Alice selecionando um nó ao qual ela está conectada, Nó (N), e enviando Atom (αX), solicitando que uma Prova Temporal de um comprimento específico seja criada.
Ao receber a solicitação, o Node (N) irá, se estiver armazenando o fragmento de Alice ou Bob, realizar uma validação do Atom (αX) No caso de ele ter uma cópia do Fragmento (1) para Alice, ele irá garantir que o Item (α) hasn'já foi gasto por Alice. Se qualquer discrepância comprovável for encontrada, como Item (α) sendo gasto por Alice ou o Atom mal construído, o processamento do Atom falhará. Caso contrário, o Nó (N) irá determinar um conjunto de nós diretamente conectados que estão armazenando qualquer Fragmento (1∥3), selecione um ao acaso e encaminhe a solicitação de envio. Se um nó adequado não for encontrado, o Nó (N) irá pesquisar através de seu gráfico de nó e metadados associados para descobrir relés viáveis com conexões para nós que mantêm o fragmento (1∥3). Após o Nó (N) descobrir um candidato adequado, o Nó (P), ele acrescentará uma coordenada espaço-temporal (l, e, o, n) e uma assinatura de Hash (l, e, o, n) à Prova Temporal (criando um novo se nenhum ainda estiver presente). Onde l é o valor lógico do relógio do Nó (N) para o evento, o é o ID do Nó observador (N), n é o ID do Nó (P) e e é o Hash do evento (Atom). O Nó (N) irá então transmitir o Atom (αX) e a Prova Temporal para Nó (P) atual.

Figura 4: Prova Temporal

Ao receber o envio do Node (N), o Node (P) também validará o Atom (αX) e, se bem-sucedido, selecionará um nó subsequente para encaminhar o envio, anexará sua coordenada (l, e, o, n) e assinatura à Prova Temporal e transmitirá o Atom (αX) e a Prova para o próximo nó. O processo se repete até que o número necessário de nós tenha participado da Prova Temporal ou uma discrepância comprovada seja descoberta por qualquer nó envolvido no processo.

Figura 5: Provisionamento de prova temporal e fofoca do Atom (α X)

Eficiência de provisionamento
O comprimento de uma Prova Temporal define quantos nós devem fazer parte do processo de provisionamento. Um comprimento muito curto reduz a eficiência de resolução de conflitos entre átomos, caso ocorram, e pode resultar em um Atom não ser verificado corretamente, exigindo que ele seja submetido ao determinismo de ordem temporal em cada nó. Comprimentos muito longos aumentam desnecessariamente a carga de largura de banda na rede, bem como o tempo que leva para um Atom se tornar final.
Uma vez que o comprimento da Prova Temporal foi determinado, se o Atom sendo transmitido tiver dependências ou Consumíveis, a rede também pode otimizar a seleção de nós para melhorar a velocidade futura de verificação dessa transferência. Isso ocorre porque um histórico causal auditável pode ser facilmente criado se um nó que estava envolvido na validação de uma transação anterior, na qual essa transação depende, for incluído na nova prova temporal.
Em termos simples, se Alice enviar Item (α) para Bob, e Bob então enviar Item (α) para Carol, será altamente benéfico para a eficiência da rede se um dos nós que estiveram envolvidos na criação da Prova Temporal para Alice → A transferência de Bob também faz parte da Prova Temporal para o Bob → Transferência de Carol.
Alcançar a história causal da Prova Temporal é relativamente simples: se, ao participar do Provisionamento Temporal, quaisquer nós candidatos disponíveis para o Nó (N) também fazem parte da Prova Temporal de quaisquer dependências do Atom (αn), Node(N) will select at random one of those as a priority if not already part of the Temporal Provisioning for Atom(αX)
Para aumentar a probabilidade de criar uma Prova Temporal com essas propriedades, o comprimento é novamente um fator importante. Para a maioria das finalidades, log (n)∗3 ou Max (3, sqrt (n)) deve ser suficiente, onde nn é um tamanho estimado dos nós presentes na rede naquele momento.

Compromissos
Para auxiliar na determinação da ordem total de eventos, os nós declaram à rede um compromisso periódico de todos os eventos que eles viram.
Este compromisso é produzido quando um nó participa do Provisionamento Temporal para um evento, ou à vontade durante um intervalo arbitrário. Um compromisso é um Merkle Hash construído a partir dos eventos que um nó testemunhou desde o envio de um compromisso anterior, com a primeira folha sendo o último compromisso enviado por um nó, produzindo uma sequência vinculada de compromissos ao longo do tempo.

Figura 6: Sequência de Compromisso

Se o nó estiver participando de um processo de provisionamento temporal, o compromisso é incluído na coordenada temporal de um nó como c, resultando na coordenada espaço-tempo estendida (l, e, o, n, c). O compromisso é à prova de violação, pois as coordenadas são assinadas pelos nós de produção.


Figura 7: Prova Temporal com Compromisso
Um nó pode ser solicitado a fornecer informações para permitir a verificação de quaisquer compromissos que tenha produzido a qualquer momento. Eles devem entregar todos os hashes Atom relevantes para o nó solicitante, permitindo que ele reconstrua o hash de confirmação e verifique. Os nós solicitantes podem então tomar as medidas adequadas no caso de detecção de um compromisso fraudulento.
Essa incerteza de quando uma verificação de confirmação pode ser solicitada também evita que os nós adulterem seus valores de relógio lógico, pois todos os compromissos têm um valor de relógio lógico associado a eles e, portanto, a violação é facilmente detectável.
Radix tem uma abordagem educacionalvideonesse assunto.

Nós Públicos
Qualquer pessoa pode executar um Radix Node na rede pública; esses nós são responsáveis por validar eventos, retransmitir mensagens e executar scripts na rede.
Coletivamente, esses serviços são chamados de “Trabalho” - a quantidade de Trabalho que um Nó pode realizar para a rede é diretamente proporcional aos recursos gerais de computação desse Nó.
Para que uma rede pública funcione de forma eficaz, é esta Obra que deve ser recompensada.

Trabalhos
No Radix, todo o trabalho é empacotado em objetos chamados Atoms. O trabalho é simplesmente uma questão de executar todos os átomos submetidos ao Universo, desde que o Atom seja válido e tenha uma taxa suficiente para cobrir o custo de execução.

Fragmento de espaço
Uma rede Radix pública (Universe) é segmentada em um espaço de fragmentos muito grande (atualmente 18,4 quintilhões de fragmentos). O ponto inicial e final para qualquer Atom no Universo Radix é um endereço, que é formado por uma chave pública e uma soma de verificação do Universo. O número de shard de um endereço é calculado de forma determinística tomando um módulo de uma chave pública sobre o espaço total de shard para derivar o índice de shard. Isso torna trivial para qualquer pessoa calcular corretamente o fragmento em que vive uma chave pública.
Devido ao tamanho do espaço do fragmento, a probabilidade de dois endereços gerados aleatoriamente morarem no mesmo fragmento é muito baixa. Isso significa que a maioria das transações convencionais tocará em dois (ou mais) fragmentos.
No início, todos os nós que se juntam à rede Radix serão capazes de manter todos os fragmentos simultaneamente, já que a maioria estará vazia, e o custo de recursos para manter um fragmento vazio é essencialmente zero. À medida que a rede cresce, cada nó não será capaz de manter todos os fragmentos e precisará remover os fragmentos até que os requisitos de recursos correspondam aos seus próprios recursos disponíveis.
Cada nó deve calcular quais shards deseja manter e quais deseja eliminar. Uma boa estratégia para isso é selecionar o conjunto de fragmentos no qual você tem a maior probabilidade agregada de ser selecionado para ajudar a criar uma Prova Temporal. Isso ocorre porque o número de Provas Temporais que um Nó ajuda a criar afeta diretamente as recompensas - parcela das taxas e emissão de novos suprimentos - que um Nó recebe, o que significa que cada Nó deseja ser incluído no máximo de Provas Temporais possíveis.
Para qualquer Prova Temporal fornecida, apenas os Nós que mantêm pelo menos um dos fragmentos que o Atom toca podem estar no conjunto de seleção. Por exemplo, Bob no Fragmento (1) envia um token para Alice no Fragmento (2), apenas os nós que mantêm o Fragmento (1) e / ou Fragmento (2) podem ser escolhidos para criar a Prova Temporal.
Como o comprimento do caminho de uma Prova Temporal é logarítmico para os Nodes disponíveis que mantêm os shards necessários, os Nodes selecionarão naturalmente os shards com o menor número de Nodes ativos como uma proporção para a atividade nesses shards.
Esse comportamento cria um mosaico sobreposto de nós que mantém diferentes configurações de fragmentos, com cada nó incentivado a procurar fragmentos ativos, mas com manutenção insuficiente, para maximizar a recompensa pelo trabalho útil realizado.

Equipe
A equipe da Radix consiste em um grupo de empreendedores em série, nômades digitais e desenvolvedores de software experientes.


Dan Hughes- Diretor de Tecnologia. Antes de descobrir o Bitcoin em 2011, Dan ajudou a desenvolver o software necessário para implementar com segurança pagamentos baseados em NFC em telefones móveis. Anteriormente, ele construiu, executou e saiu de 3 startups de software de sucesso. Dan passou os últimos 6 anos construindo, testando e refinando seus próprios protocolos DLT, criando Radix no processo.
Piers Ridyard- CEO. Um empreendedor em série, Piers começou na Blockchain experimentando a criação de contratos inteligentes de seguro que poderiam operar sem a necessidade de uma operadora no início de 2015. Antes de assumir o comando da Radix, ele co-fundou a Surematics, uma YCombinator S ' 17 empresa, ajudando a criar a primeira sala de dados descentralizada do mundo.
Robert Olsen- Diretor de operações. Empreendedor em série, verdadeiro nômade digital e super networker, Rob tem sido um criptocompensador e evangelista de blockchain desde 2012. Com base em sua considerável experiência em operações, Rob continua a aprimorar as operações Radix, marketing, relações públicas, comunicações comunitárias exposições e presença nas redes sociais.


Stephen Thornton- Chief Scientist.Um especialista em física, criptografia e desenvolvimento de software, Steve criou a primeira Internet criptografada privada transatlântica, ajudou a desenvolver SSLEAY, portou openSSL para rodar em plataformas móveis usando soquetes assíncronos e escreveu o firmware para roteadores mesh criptografados para o ' MoD. Ele agora desenvolve e valida a segurança, lógica e resiliência da rede Radix e algoritmos.

Shira Abel- CMO em exercício. Uma comerciante experiente que fundou a Hunter & Bard e foi CMO em exercício em várias startups de alto crescimento, Shira usa sua vasta experiência e conjunto de habilidades para ajudar a construir empresas de sucesso. Como CMO em exercício da Radix, Shira analisa e presta consultoria em tudo o que é marketing: mensagens, estratégia de crescimento, mídia social, relações públicas, relações de desenvolvimento, eventos e muito mais.

Zalán Blénessy- Operações de desenvolvedor. Anteriormente, Zalan ajudou empresas como a ST Ericsson a criar sistemas operacionais móveis eficientes antes de contratar a Apple, resolvendo problemas de implantação em grande escala. Zalan extraiu seus primeiros Ethers em 2015 e foi imediatamente fisgado. Ele agora garante que os desenvolvedores do Radix sejam tão eficazes quanto possível, permitindo que eles se concentrem em levar o Radix para o próximo nível.

Marc Rubio- Desenvolvedor. Um desenvolvedor Android, iOS e Web com mestrado em engenharia eletrônica, Marc usa seu conjunto diversificado de habilidades para ajudar a informar o design e a implementação dos primeiros aplicativos móveis baseados em Radix. Marc se envolveu com a comunidade e com todas as coisas descentralizadas desde 2013, sendo fisgado primeiro pelo Bitcoin e depois descobrindo o Radix.

Joshua Primero- Desenvolvedor. Um generalista de software e ninja em Java, Josh tem mexido na pilha de software nos últimos 10 anos. Desde escrever drivers de GPU para NVIDIA até desenvolver aplicativos full stack para várias startups, ele se interessa por tudo. Ele agora traz sua experiência em engenharia e execução para a Radix, ajudando a mover a base de código do teste para a produção.

Edgars Nemse- Developer.Edgars parou de estudar IA na Universidade de Edimburgo para cofundar a Edurio, uma startup de tecnologia educacional, atraindo mais de US $ 2 milhões em financiamento, ajudando a construir ferramentas melhores para professores e alunos. Depois de seguir a cena da criptografia desde os primeiros dias do Bitcoin, ele agora está na Radix procurando aplicar sua magia em toda a pilha.

Mauricio urraco- Desenvolvedor. Um desenvolvedor full stack que gosta de uma abordagem pragmática à engenharia: prototipagem, lançamento antecipado e experimentação. Com uma ampla gama de experiência técnica, incluindo trabalho como engenheiro de pesquisa no INRIA, ele decidiu se juntar à Radix e mergulhar fundo no mundo das tecnologias de razão distribuída.

Florian Cäsar- Desenvolvedor. Um arquiteto de software apaixonado por toda a linha, Florian desenvolveu diversos projetos de software que vão desde jogos de quebra-cabeça indie até uma estrutura de aprendizado de máquina premiada. Depois de completar seu serviço militar como pesquisador da OSINT, ele agora projeta e implementa a plataforma e a linguagem Scrypto enquanto auxilia na preparação de outros aspectos do Radix para produção.

Angad Mutha- Gerente de comunidade. Antes da Radix, Angad ajudou a escalar startups de empresas em San Francisco. Um desenvolvedor da web por profissão e um profissional de marketing em crescimento por opção, ele está em ambos os lados da cerca. Ele ficou obcecado por protocolos descentralizados depois de receber seu primeiro bitcoin em 2011. Na Radix, ele é responsável pela gestão da comunidade e marketing digital.

David Osuhon- Chefe de Projetos Especiais. David foi anteriormente Chefe de Equipe de uma startup em rápido crescimento no Reino Unido e vem para a Radix como Chefe de Projetos Especiais. Tendo trabalhado para empresas como Tangle Teezer e Bank of America, David agora traz suas habilidades de liderança e gerenciamento de projetos para a Radix.
Eoutras.
A Radix não tem nenhum consultor listado em seu site.

Caso de uso
Todos os casos de uso do Radix são centralizados em torno de seu recurso de escalabilidade e capacidade de integração com soluções de ponto de venda (POS) existentes do comerciante
Stable Value Tokens - para proteger os consumidores e comerciantes de grandes oscilações de preços
Scrypto - uma linguagem de contrato inteligente completa Turing semelhante ao JavaScript
Cartões de débito descentralizados com trilhos de pagamento DLT que são compatíveis com os sistemas existentes de pontos de venda do comerciante
Troca descentralizada para negociação sem confiança de ativos digitais
Clientes seguros de mensagens instantâneas ponto a ponto e comunicação por e-mail
Mercado de bens e serviços
Appstore para aplicativos descentralizados construídos na Rede Pública Radix

Roteiro
A Radix será lançada como uma rede pública no primeiro trimestre de 2019, quando as pessoas poderão comprar ou ganhar tokens Radix.
O Radix também está trabalhando para permitir:
- Tokens de baixa volatilidade do mercado de massa
- Trilhos de pagamento com cartão DLT
- mensagens instantâneas P2P
- Mecanismos de troca descentralizados

2018 - quarto trimestre
Meta: 1.000.000 de transações por segundo
API de criação de token de terceiros ativa na rede de teste Alpha
Transações multi-sig e timelocked ao vivo na Alpha Test Net
Programado: White Paper do Exchange descentralizado
Programado: White Paper de Economia

2019 - 1º trimestre
Lançamento: Radix Main Net - Radix Tokens apenas
Lançamento: carteiras Radix e mensagens na rede principal
Início da distribuição do token Radix
Tokens de terceiros habilitados na rede principal
Scrypto restrito lançado na rede de teste beta

2019 - 2º trimestre
Radix Naming Service habilitado na rede de teste beta
Scrypto restrito lançado na rede principal

2019 - 3º trimestre
Turing Complete Scrypto lançado na Alpha Test Net
Radix Naming Service habilitado na rede principal

Mecânica de token
Incentivos
Provas temporais funcionam como um registro público do trabalho realizado por cada nó na rede, permitindo uma forma rápida e auditável de determinar quem fez o trabalho e em que proporção.
O custo do usuário final para processar um Atom é proporcional à complexidade de sua execução. Semelhante ao preço do gás Ethereum, é cobrado um custo de execução por byte. Inicialmente uma taxa mínima será definida pela equipe da Radix, mas posteriormente esse custo será definido de acordo com o consenso da rede.
Os incentivos da rede pública são divididos em dois componentes principais: taxas de execução e novas emissões.
Uma taxa de execução é ganha por um Nó quando ele participa da criação de uma Prova Temporal válida. Em uma Prova Temporal de comprimento de caminho nn, a recompensa do Nó é calculada como: Taxa de Execução Atom / n.
Ou seja, um Nó em uma Prova Temporal com um comprimento de caminho de 10 receberá 10% da taxa de execução total devida para o processamento desse Atom. Essa taxa está disponível para ser gasta quase imediatamente.
O número de Provas Temporais nas quais um Nó está incluído também ajuda a determinar a quantidade de novas emissões que o Nó receberá. As novas emissões são definidas pela economia do token Radix e podem ser fixas ou variáveis. Isso será abordado em detalhes no próximo White Paper da Radix Economics.
Inicialmente, a principal recompensa por operar um Node será a emissão de um novo suprimento. Conforme a rede cresce e o número de transações / operações conduzidas na rede aumenta, as taxas representam uma proporção cada vez maior das recompensas e incentivos.

Mecanismo de taxa
Quando uma taxa é paga na rede pública, a parte da taxa do Atom é retida assim que a Prova Temporal é criada. Não é coletado por ninguém nessa fase, simplesmente desaparece.

Figura 8: Taxas de transação

O pagamento da taxa de processamento de um Atom é semelhante ao modelo Bitcoin UTXO: o endereço da carteira de Alice contém 10 tokens e ela deseja enviar 9,25 para Bob. Alice especificará 9,25 para Bob e o restante, menos a taxa, de volta para ela. Isso cria:
• 9,25 tokens para Bob
• 0,25 tokens de volta para Alice
• 0,5 tokens como taxa
A taxa não é “paga”, ela simplesmente faz parte do total da transação não reclamada. Um Nodo pode reivindicar sua parte da taxa gastando o que é devido a ele. Eles fazem isso criando um Transaction Atom que inclui um Consumidor que faz referência ao Atom que contém as taxas devidas.
Na Figura 8 acima, Bob também ganhou uma taxa de 0,25. Isso porque ele também foi um nó validador da Prova Temporal da transação de Alice para ele.
Bob agora paga 9 tokens para Carol e também precisa pagar uma taxa de transação de 0,5 token. Ele paga 9,25 tokens de sua própria carteira e os outros 0,25 da taxa que ganhou por validar a Prova Temporal da transação Alice para Bob.
Também é importante observar que o gasto de taxas devidas tem uma relação causal com o Atom que criou a taxa. Como resultado, o Atom que gasta a parte da taxa não pode atingir a finalidade antes do Atom original. Por exemplo, se o gasto de Alice com Bob acabar sendo inválido, a transação de Bob com Carol também falhará.


Métricas de token
O Radix é capaz de oferecer suporte a vários tipos de modelos de fornecimento de tokens criptoeconômicos. Isso inclui fixo, linear, indexado e inflacionário. Os tokens de valor estável Radix seguem um suprimento inflacionário dinâmico, portanto, não há limite rígido.
Os tokens radix terão um período inicial curto indexado ($ 1 = 1 RDX) após o qual o token poderá flutuar livremente. À medida que a demanda pela moeda aumenta, a circulação total da moeda de baixa volatilidade Radix também aumentará.
Se a demanda for reduzida, o sistema também terá alguns mecanismos para queimar tokens em circulação. Se esses sistemas falharem, a moeda diminuirá de valor, em termos reais, em relação a outras moedas (como o dólar), até que a demanda se recupere.

DISTRIBUIÇÃO DE RADIX TOKEN
Este gráfico mostra a distribuição (ceteris paribus) como uma% da oferta total (24Bn RADIX TOKENS).



Recursos oficiais:
Site: https://www.radixdlt.com/
Whitepaper :
- https://www.radixdlt.com/wp-content/uploads/2020/03/Cerberus-Whitepaper-v1.0.pdf
- https://www.radixdlt.com/wp-content/uploads/2020/06/2020-04-03-Radix-Economic-Model-V6.pdf
facebook: https://www.facebook.com/RadixDLT/
Twitter: https://twitter.com/RadixDLT
Telegrm: https://t.me/radix_dlt
Reddit: https://www.reddit.com/r/Radix/
Medium: https://medium.com/@radixdlt

Autor:
Altcoinstalks Name: rezanahvi
Altcoinstalks URL: https://www.altcoinstalks.com/index.php?action=profile;area=summary;u=21385
Telegram ID: @Hommai

« Last Edit: October 04, 2020, 06:43:19 PM by rezanahvi »
████ ███ ██ █    CYCLOPS FINANCE    Decentralized Gaming and NFT Ecosystem    █ ██ ███ ████
//   WEBSITE   //   WHITEPAPER   //   TELEGRAM GROUP   //   TWITTER   //   GITHUB   //   MEDIUM   //   YOUTUBE   //
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  Powered by BOUNTY DETECTIVE  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Altcoins Talks - Cryptocurrency Forum


For Monthly biddings Check Here


Offline ShadowCrypto

  • Legendary
  • *
  • *
  • *
  • Activity: 1472
  • points:
    35873
  • Karma: 40
  • Trade Count: (0)
  • Referrals: 1
  • Last Active: March 26, 2024, 12:04:12 AM
    • View Profile

  • Total Badges: 24
    Badges: (View All)
    Fifth year Anniversary Fourth year Anniversary 10 Posts
Re: RadixDLT, O Protocolo de Finanças Descentralizadas (revisão completa)
« Reply #1 on: October 02, 2020, 07:21:54 PM »
Voce deveria mover este topico para o lugar certo aqui no forum: https://www.altcoinstalks.com/index.php?board=99.0
Tem a seção especifica para postar sobre criptomoedas alternativas.

 

ETH & ERC20 Tokens Donations: 0x2143F7146F0AadC0F9d85ea98F23273Da0e002Ab
BNB & BEP20 Tokens Donations: 0xcbDAB774B5659cB905d4db5487F9e2057b96147F
BTC Donations: bc1qjf99wr3dz9jn9fr43q28x0r50zeyxewcq8swng
BTC Tips for Moderators: 1Pz1S3d4Aiq7QE4m3MmuoUPEvKaAYbZRoG
Powered by SMFPacks Social Login Mod