*Reencaminhe o título original：Relatório de pesquisa da Eureka Partners: Singularidade - Transacções de Privacidade numa Blockchain Transparente

Introdução

Em 1969, o método de negociação nos mercados financeiros ainda se baseava nos pregões tradicionais. Nessa altura, a tecnologia informática ainda não estava madura e os operadores dependiam de gritar as ordens em voz alta, um método ineficaz e sem privacidade, que dificultava aos investidores institucionais a realização de grandes transacções sem causar flutuações no mercado. A Instinet, fundada por Jerome Pustilnik, surgiu em resposta a este desafio. A Instinet permitia que os investidores colocassem ordens anonimamente através de uma plataforma de negociação eletrónica, que era responsável pela correspondência entre as ordens dos compradores e dos vendedores e pela execução das transacções. Este modelo não só melhorou a eficiência da negociação, como também assegurou a confidencialidade das transacções, evitando eficazmente o impacto no mercado e a fuga de informação.

Atualmente, os avanços tecnológicos conduziram ao nascimento da tecnologia blockchain, uma inovação revolucionária que trouxe uma transparência e segurança sem precedentes às transacções financeiras. No entanto, a natureza pública e a imutabilidade da cadeia de blocos, embora tragam muitos benefícios ao mercado, também apresentam novos desafios para os operadores de grandes transacções. No livro-razão público da cadeia de blocos, todas as transacções são visíveis para todos os participantes, o que dificulta o anonimato dos comerciantes de grandes transacções. As plataformas de negociação tradicionais não podem proteger totalmente a privacidade dos operadores e a divulgação pública de grandes encomendas pode levar a flutuações de preços, afectando a eficiência e os custos da negociação. Além disso, a incerteza regulamentar e a opacidade do mercado também representam riscos adicionais para os investidores.

Este relatório irá explorar as dark pools na cadeia de blocos como uma solução inovadora que introduz tecnologias avançadas de proteção da privacidade e mecanismos de negociação automatizados para proporcionar um ambiente mais seguro e eficiente para grandes transacções de criptomoedas. Também discutirá como a Singularity, através de suas soluções inovadoras que utilizam tecnologias como FHE (Fully Homomorphic Encryption) e ZKP (Zero-Knowledge Proof), oferece aos grandes investidores uma plataforma de negociação descentralizada privada e compatível.

O que é Dark Pools？

Os Dark Pools nos mercados financeiros tradicionais referem-se a plataformas de negociação privadas que não divulgam publicamente informações sobre as transacções, permitindo aos investidores realizar grandes transacções sem expor as suas intenções de negociação. O aparecimento da negociação em dark pool nos Estados Unidos está estreitamente relacionado com a procura crescente de transferências de acções em grande escala devido à frequência crescente de fusões e aquisições no mercado de valores mobiliários. Com o desenvolvimento dos mercados financeiros, a importância dos "dark pools" em vários domínios, como as acções, as obrigações e as divisas, tornou-se cada vez mais proeminente, especialmente na era em que dominam as negociações de alta frequência e algorítmicas. As estatísticas revelam que as transacções de dark pool representam 30% a 50% do mercado bolsista, tornando-se uma componente importante da liquidez do mercado.

No mercado das criptomoedas, à medida que o grupo de grandes investidores cresce, a procura de transacções de grande volume continua a aumentar. Estas grandes encomendas têm um impacto significativo no mercado, chegando por vezes a provocar perturbações no mercado. Para evitar estes riscos, muitos comerciantes recorrem ao mercado OTC ou mesmo a grupos do Telegram para efetuar transacções. De acordo com dados da bolsa Kraken em 2020, o volume global de transacções OTC aumentou 20 vezes desde 2018, com um volume médio diário de transacções de aproximadamente 300 mil milhões de dólares, representando quase 70% do volume total de transacções do mercado de criptomoedas. No entanto, o mercado OTC também enfrenta problemas de liquidez insuficiente e falta de regulamentação. Para fazer face a estes desafios, foram introduzidos os "dark pools" como solução, com o objetivo de proporcionar um ambiente de negociação mais estável e privado.

Os pontos principais sobre as dark pools incluem:

• Privacidade e confidencialidade: Os Dark pools permitem que os operadores efectuem transacções de forma anónima, protegendo a sua identidade e o tamanho da ordem do mercado público até que a transação seja executada.

• Impacto reduzido no mercado: Os Dark pools permitem que os grandes investidores institucionais executem grandes ordens sem causar flutuações significativas de preços no mercado público, minimizando o impacto no mercado e a derrapagem.

• Não divulgação de estratégias de negociação: As transacções dark pool ajudam a proteger as estratégias dos negociadores de serem conhecidas pelo mercado público, evitando que sejam exploradas por MEV (Miner Extractable Value), arbitragem de copy trading e arbitragem estatística.

• Liquidez e melhoria dos preços: Os Dark pools proporcionam liquidez adicional ao mercado, fazendo corresponder compradores e vendedores que podem não encontrar contrapartes nas bolsas tradicionais, oferecendo potencialmente melhorias de preços, especialmente para transacções de grande volume.

• Supervisão regulamentar: As dark pools são regulamentadas, com os organismos reguladores a monitorizarem as actividades das dark pools para evitarem o acesso desleal, o abuso de informação privilegiada ou a manipulação do mercado. No entanto, para muitas dark pools, o estilo de gestão centralizada ainda apresenta riscos de segurança, fiabilidade e potencial utilização indevida de dados privados. Historicamente, houve vários casos em que os dark pools centralizados foram penalizados por violarem os princípios de confiança.

Principais tecnologias de privacidade

Os pools escuros são um ramo da pista de privacidade. Através das seguintes tecnologias de reforço da privacidade (PET), como as provas de conhecimento zero (ZKP), a computação multipartidária (MPC) e a encriptação totalmente homomórfica (FHE), as dark pools injectam privacidade na sua infraestrutura.

Prova de conhecimento zero (ZKP)

A tecnologia Zero-Knowledge Proof (ZKP) permite que um provador prove a correção de uma afirmação a um verificador sem revelar qualquer informação substantiva. Esta tecnologia é particularmente crucial nas soluções de escalonamento da Camada 2 do Ethereum, como o ZK Rollup, que consegue a verificação da validade da transação comprimindo os dados da transação em provas ZK compactas e submetendo-as à rede principal. Estas provas não só ocupam um espaço de armazenamento mínimo, como também protegem a privacidade da informação da transação, incorporando as vantagens naturais de um mecanismo sem confiança. A aplicação da tecnologia ZKP não se limita ao escalonamento, mas inclui também a computação da privacidade, sendo as suas principais implementações os zkSNARKs, zkSTARKs e Bulletproofs. Estas tecnologias promovem coletivamente o reforço da proteção da privacidade das criptomoedas e a eficiência das transacções.

Introdução às provas de conhecimento zero

Computação multipartidária (MPC)

A computação multipartidária (MPC) é uma tecnologia que permite que várias partes calculem uma função em conjunto sem revelar as suas entradas individuais. No domínio da privacidade, a MPC fornece um método para proteger dados sensíveis, permitindo que as partes efectuem análises de dados, tarefas de computação ou tomem decisões sem expor dados pessoais. A principal vantagem da MPC reside na sua capacidade de proteção da privacidade. Através de tecnologias de computação distribuída e de encriptação, os participantes podem garantir que os seus dados permanecem privados durante todo o processo de computação.

Introdução à computação segura multipartidária

Encriptação totalmente homomórfica (FHE)

A encriptação totalmente homomórfica (FHE) é uma tecnologia criptográfica que permite a computação direta em dados encriptados sem necessidade de os desencriptar primeiro. Isto significa que operações como a adição, a subtração e a multiplicação podem ser efectuadas sobre os dados enquanto estes permanecem encriptados e que os resultados do cálculo, uma vez desencriptados, são coerentes com os obtidos através da realização das mesmas operações sobre os dados originais. O valor central da FHE reside no facto de fornecer uma ferramenta poderosa para a proteção da privacidade, permitindo que os dados permaneçam confidenciais durante o processamento, aumentando assim significativamente a segurança dos dados.

Equilíbrio entre anti-censura e conformidade

As trocas descentralizadas (DEXs) que operam em blockchains públicos, como Uniswap e Curve, são suscetíveis ao Valor Máximo Extraível (MEV) devido à natureza pública e transparente de seus livros-razão. Esta transparência significa que os detalhes das encomendas são visíveis para todos, permitindo que os pesquisadores e construtores optimizem os seus lucros através da reorganização das ordens de transação, o que pode afetar negativamente outros utilizadores até certo ponto.

As Dark pools, enquanto forma de negociação financeira, têm como principais vantagens a proteção da privacidade e a anti-censura. Nas dark pools, os detalhes das ordens são geralmente mantidos em segredo de terceiros, uma vez que cada ordem gera Zero-Knowledge Proofs (ZKPs), reduzindo a divulgação pública de informações sobre a transação. Esta arquitetura é particularmente apelativa para os grandes detentores e investidores institucionais, uma vez que protege as suas estratégias de negociação de serem exploradas por concorrentes ou manipuladores de mercado. Além disso, as características das dark pools também ajudam a resistir ao MEV, uma vez que a ordem e os detalhes das transacções não são públicos, reduzindo a possibilidade de rearranjo.

No entanto, estas vantagens podem diminuir quando as transacções precisam de chamar contratos públicos ou utilizar sequenciadores partilhados, uma vez que estas operações podem expor informações sobre a transação, proporcionando oportunidades de captura de MEV. No entanto, para os grandes detentores e investidores institucionais que procuram proteção da privacidade e anti-censura, especialmente quando as suas actividades de negociação exigem uma elevada confidencialidade, as dark pools continuam a ser uma opção atractiva.

O aparecimento de ferramentas de proteção da privacidade, como a Tornado Cash, oferece a possibilidade de realizar actividades financeiras anónimas na cadeia, mas estas ferramentas também têm sido utilizadas por criminosos para actividades ilegais, como o branqueamento de capitais. O endereço do contrato inteligente da Tornado Cash foi listado pelo Office of Foreign Assets Control (OFAC) devido a não conformidade. O OFAC mantém uma lista de Cidadãos Especialmente Designados (SDN) para sancionar indivíduos e entidades não conformes. Os protocolos que não estão em conformidade com os regulamentos OFAC têm uma elevada probabilidade de as suas transacções serem excluídas dos blocos na cadeia. A partir de 23 de fevereiro de 2024, 45% dos blocos requerem uma revisão da lista OFAC. Esta questão anti-censura afecta não só os produtores de blocos, mas também os validadores e retransmissores, que podem ignorar seletivamente certas transacções ou blocos.

Proporção de blocos analisados pelas listas do OFAC

Com a proibição da Tornado Cash por falta de conformidade, surgiu um vazio no mercado de soluções de privacidade compatíveis. Para preencher este vazio, os projectos subsequentes de "dark pool" têm de proporcionar proteção da privacidade, evitando riscos regulamentares semelhantes. Um método eficaz é a integração de processos KYB/KYC verificados no projeto, garantindo a legalidade das actividades do utilizador e ajudando a evitar potenciais riscos regulamentares. Os regulamentos legais estão frequentemente atrasados em relação aos avanços tecnológicos, tornando os projectos de privacidade facilmente exploráveis para actividades ilegais. A adoção e o cumprimento ativo dos regulamentos são cruciais para garantir a segurança e a legalidade do projeto.

Cenário da concorrência & Análise de projectos

Entre 2010 e 2022, o número de projectos de "dark pool" foi limitado e estes projectos não obtiveram um reconhecimento generalizado entre o público em geral. No entanto, com o avanço das tecnologias de reforço da privacidade, como as Zero-Knowledge Proofs (ZKP) e a Multi-Party Computation (MPC), o domínio das "dark pool" acolheu uma série de soluções tecnológicas inovadoras. O desenvolvimento destas tecnologias fez com que as dark pools voltassem a ser objeto de atenção pública em 2023. No entanto, devido à complexidade da tecnologia, o número de projectos na corrida ao dark pool é ainda relativamente pequeno. Eis alguns projectos que se tornaram relativamente maduros.

1. A Renegade, criada em 2022, é uma dark pool descentralizada baseada na arquitetura MPC-ZKP, concebida para fornecer serviços de grandes transacções a investidores institucionais. A Renegade efectua a correspondência de encomendas através de uma rede peer-to-peer e da tecnologia Multi-Party Computation (MPC) e utiliza ZK-SNARKs para garantir que os detalhes da transação permanecem anónimos para terceiros durante o processo de verificação da correspondência de encomendas. Além disso, utiliza um mecanismo de execução de ponto médio para garantir que todas as transacções são diretamente liquidadas ao preço médio agregado em tempo real das bolsas centralizadas para evitar derrapagens. A sua funcionalidade de negociação cruzada anónima por defeito, combinada com indicadores de interesse, promove a descoberta abrangente de preços e optimiza a liquidez.

2. Penumbra é uma plataforma de negociação descentralizada construída dentro do ecossistema Cosmos, oferecendo um ambiente de negociação do tipo dark pool que permite aos utilizadores negociar enquanto mantêm a privacidade. Através de um mecanismo de delegação privado, a Penumbra combina a proteção da privacidade e o mecanismo de consenso Proof-of-Stake (PoS), oferecendo derivados de staking, staking eficiente em termos fiscais e governação on-chain com votação privada. A Penumbra liga-se ao ecossistema Cosmos através da Comunicação Inter-Blockchain (IBC), servindo como uma dark pool de todo o ecossistema que permite transacções privadas em qualquer ativo compatível com IBC. Os utilizadores também podem utilizar o ZSwap, uma bolsa privada descentralizada que suporta leilões de lotes de ofertas seladas e liquidez concentrada semelhante ao Uniswap-V3, para trocar estes activos.

3. A Panther é uma plataforma DeFi de cadeia cruzada que incorpora tecnologia de conhecimento zero, destinada a fornecer uma solução que está em conformidade com a regulamentação e protege a privacidade do utilizador. Os utilizadores podem depositar activos digitais nos Multi-Asset Shielded Pools (MASPs) da Panther e receber zAssets numa base 1:1. Através do módulo Zswap, o Panther liga-se a outros protocolos DeFi, agregando cotações para seleção do utilizador. Durante as transacções, o Zswap cria um contrato de garantia encriptado, permitindo que os utilizadores troquem activos sem revelar os detalhes da transação. Esta conceção permite que os activos coexistam em diversos conjuntos, mantendo a heterogeneidade dos dados e dificultando o rastreio e a desanonimização dos utilizadores. As piscinas blindadas Panther utilizam a tecnologia ZK SNARK e ZKP para garantir a privacidade e a conformidade das transacções.

4. O Railgun é um sistema de privacidade com uma arquitetura ZKP-MPC concebida para Ethereum, BSC, Polygon e Arbitrum, utilizando a tecnologia de encriptação de conhecimento zero (ZK) e tirando partido da tecnologia MPC para a cerimónia de configuração de confiança. Permite aos utilizadores executar contratos inteligentes e operações DeFi de forma segura, mantendo a privacidade das transacções. Quando os utilizadores emitem ordens de transação através do Railgun, um contrato inteligente do Módulo Adapt processa automaticamente a desativação da privacidade do saldo privado, valida a ordem e, em seguida, procura a melhor taxa de câmbio na liquidez DEX agregada, voltando finalmente a proteger os activos da transação para garantir o anonimato da atividade e dos endereços dos utilizadores. Este processo não se aplica apenas às trocas de activos, podendo também ser alargado a outros tipos de transacções DeFi.

Interpretação técnica da Singularidade:

Como implementar transacções privadas

Compreender o conceito de transacções privadas

Para compreender o conceito de transacções privadas, é essencial considerar tanto as partes envolvidas na transação como as especificidades da mesma, diferenciando entre dois tipos de privacidade: anonimato e ocultação.

Uma transação standard inclui os seguintes elementos:

• Partes da transação: Inclui o remetente (Negociador A) e o destinatário (Negociador B) da transação.

• Detalhes da transação: Inclui o montante da transação, o número de sub-transacções, o hash da transação e outros detalhes específicos.

As transacções privadas podem ser classificadas em dois tipos com base no nível de visibilidade da informação para terceiros:

• Transacções anónimas: Nas transacções anónimas, os endereços do remetente e do destinatário são desconhecidos de terceiros. Isto significa que durante o processo de transação, exceto para as duas partes envolvidas na transação, mais ninguém pode identificar os participantes específicos. Por exemplo, o Tornado Cash é um protocolo de privacidade que consegue o anonimato ofuscando os caminhos da transação.

• Transacções ocultas: Nas transacções ocultas, embora os endereços do remetente e do destinatário sejam visíveis, os pormenores específicos da transação não são conhecidos. Isto significa que o montante da transação, o número de sub-transacções, o hash da transação e outras informações detalhadas são ocultados a terceiros. Este tipo de privacidade pode ser conseguido através de tecnologias como as ZKP (Zero-Knowledge Proofs). Por exemplo, o Zcash é uma criptomoeda de privacidade que utiliza a tecnologia zk-SNARKs para ocultar os detalhes das transacções.

Singularidade Interpretação geral da arquitetura

Visão geral da arquitetura da Singularidade

Se olhar para a estrutura geral, pode dividir-se em cerca de 5 módulos:

1. Singularidade

Este é o contrato inteligente com o qual os utilizadores interagem principalmente, utilizado para expressar e executar a lógica do circuito ZK. As funcionalidades destes contratos inteligentes incluem a ocultação do saldo e dos registos de transação dos tokens ETH/ERC20 para alcançar o anonimato e a ocultação do conteúdo das transacções. Funciona como um pool de liquidez que agrega todos os activos de todos os tipos de operadores. O seu nome deriva da sua caraterística única, ou seja, para todos os observadores, todas as transacções do protocolo parecem ter origem neste contrato inteligente. Esta conceção proporciona aos utilizadores uma privacidade multidimensional.

No protocolo Singularity, as notas ZK constituem a unidade básica das transacções, contendo informações críticas sobre a transação, incluindo o tipo de ativo, o montante e um identificador encriptado relacionado com o proprietário. A conceção destas notas visa proporcionar um elevado nível de proteção da privacidade, garantindo que as identidades dos comerciantes e as informações sobre os seus activos são efetivamente salvaguardadas.

Cada nota inclui as seguintes informações essenciais:

• Tipo de ativo: Indica o tipo de ativo envolvido na transação, como o tipo de token de uma criptomoeda ou outros activos digitais.

• Valor: Indica a quantidade de activos contidos na Nota, utilizada para determinar o valor da transação.

• Rho: Um valor de campo gerado aleatoriamente utilizado para aumentar a privacidade das transacções, impedindo que observadores externos acompanhem e analisem a transação.

• Chave pública Schnorr: Utilizada para assinatura criptográfica e verificação da identidade das transacções, garantindo que apenas os utilizadores autorizados podem efetuar operações de transação válidas.

Para além das informações acima referidas, cada Nota também gera um Nulificador correspondente. A geração de Anuladores utiliza técnicas de hashing criptográfico, tomando o valor aleatório e a chave pública da Nota como entradas e processando-os para produzir o Anulador correspondente. Esta conceção visa proporcionar uma segurança adicional às transacções, garantindo que apenas os utilizadores legítimos autorizados podem efetivamente operar e consumir a Nota.

Adição de notas e armazenamento

No protocolo Singularity, todas as Notas são anexadas a uma árvore Merkle só de anexos, e a raiz da nova árvore Merkle é permanentemente armazenada. O objetivo desta conceção é garantir a integridade e a segurança das transacções, evitando que os dados sejam adulterados e corrompidos.

Para o ilustrar com um exemplo simples:

Suponha que Alice é uma utilizadora do protocolo Singularity. A dada altura, realiza uma transação, depositando 1 ETH no contrato Singularity. Esta transação será registada como uma nota e anexada à árvore Merkle atual. Neste momento, a raiz da árvore de Merkle é calculada a partir desta única nota.

Posteriormente, Bob também realiza uma transação, depositando 0,5 ETH no contrato Singularity. Esta transação também será registada como uma Nota e anexada à árvore Merkle atual. A raiz da árvore de Merkle é actualizada à medida que são adicionadas novas notas.

Nota: No caso de ser gerado um número ímpar de notas para a raiz da árvore Merkel, as duas notas individuais serão duplicadas e os seus hashes calculados.

À medida que mais utilizadores efectuam transacções, cada nova nota é adicionada à árvore Merkel por ordem cronológica. Assim, o histórico de transacções de cada utilizador é preservado na mesma estrutura de dados e a integridade de todo o histórico de transacções pode ser eficientemente verificada calculando o hash da raiz da árvore de Merkel. Uma vez que a árvore de Merkel é só de anexação, é impossível modificar ou apagar qualquer nota que tenha sido adicionada à árvore, garantindo assim a segurança e a imutabilidade dos dados da transação.

Transação Verificação de notas

Quando os comerciantes realizam transacções, devem revelar o Nullifier correspondente e fornecer provas relacionadas na prova de conhecimento zero para verificar se o Nullifier está associado à Nota correspondente e provar a existência da Nota na árvore de Merkel. Os contratos inteligentes verificarão a exclusividade do Nullifier e a validade das provas para garantir a legalidade e a segurança da transação.

Por exemplo:

Suponha que Alice tem uma nota contendo 1 ETH que ela depositou no contrato Singularity, e o Nullifier dessa nota é "AAA123". Agora, a Alice quer utilizar estes fundos para uma transação, pelo que tem de fornecer "AAA123" como o Nullifier e provar os dois pontos seguintes através de uma prova de conhecimento zero:

1. Prove que "AAA123" está associado à nota gasta, ou seja, que os fundos para esta transação provêm efetivamente dessa nota.

2. Prove a existência da Nota na árvore de Merkel, ou seja, que a Nota foi previamente depositada no contrato de Singularidade e não foi adulterada.

O contrato inteligente verificará o Nullifier e as provas fornecidas pela Alice para garantir a exclusividade do Nullifier e a validade das provas. Só quando a verificação for aprovada é que o contrato executa a transação e transfere os fundos para o destinatário pretendido por Alice. Assim, o contrato inteligente garante a legalidade e a segurança da transação, impedindo quaisquer actividades maliciosas ou fraudulentas.

Abaixo está o pseudocódigo de implementação da lógica acima:

// Pseudocódigo
pragma solidity ^0.8.0;
contract SingularityContract {
 mapping(address => mapping(bytes32 => bool)) private invalidValues;
 mapping(bytes32 => bool) private merkleTree;
  // Operação de depósito, depositando fundos no contrato da Singularidade
 function deposit(bytes32 noteHash, bytes32 invalidValue) public payable {
       require(msg.value > 0, "Deposit amount must be greater than 0");
       // Add the Note to the Merkel tree
       merkleTree[noteHash] = true
       // Store the nullifier
       invalidValues[msg.sender][noteHash] = true;
   }
   // Operação de despesa da transação, verificando o anulador e a prova, executando a transação
 function spend(bytes32 noteHash, bytes32 invalidValue, bytes memory proof) public {
       // Verify that the provided nullifier matches the stored one
       require(invalidValues[msg.sender][noteHash], "Invalid value does not match");
       // Verify the existence of the Note in the Merkel tree
       require(merkleTree[noteHash], "Note does not exist in the Merkle tree");
       // Verify the zero-knowledge proof
       require(_verifyProof(noteHash, invalidValue, proof), "Proof verification failed");
       // Execute the transaction, transferring funds to the recipient
       // The specific transfer operation is omitted here
   }
   // Função de verificação da prova de conhecimento zero
 function _verifyProof(bytes32 noteHash, bytes32 invalidValue, bytes memory proof) private view returns (bool) {
       // In practice, specific zero-knowledge proof verification is required
       // The specific verification process is omitted here
       // If the proof is successfully verified, return true, otherwise return false
       return true;
   }
}

1. Reservar

Book utiliza a tecnologia Fully Homomorphic Encryption (FHE) para construir um livro de ordens offline completamente privado, proporcionando aos comerciantes um ambiente de negociação seguro e fiável. No sistema Book, um grupo especial de nós FHE, conhecidos como Bookies, desempenham um papel fundamental, gerindo coletivamente a carteira de encomendas. O processo de correspondência inclui:

Os nós API encriptam as encomendas para garantir a confidencialidade do conteúdo da encomenda. Em seguida, os corretores utilizam o protocolo FHE para efetuar cálculos de correspondência de ordens, salvaguardando o sigilo das informações das ordens. Os resultados da correspondência de ordens são publicados, mas o conteúdo original da ordem permanece confidencial para proteger os direitos de privacidade dos comerciantes. Os negociantes emparelhados podem comunicar diretamente e efetuar a transação utilizando a funcionalidade Swap do contrato Singularity, enquanto os negociantes que não efectuarem a transação serão penalizados em termos de reputação.

Para garantir o funcionamento estável do sistema de livros, é adotado um mecanismo de incentivo de regra de maioria, e os corretores são obrigados a apostar fichas:

• As casas de apostas utilizam um mecanismo de regra da maioria para resolver potenciais desacordos na correspondência de ordens encriptadas, impedindo actividades maliciosas.

• Os tokens de staking têm como objetivo proteger contra ataques Sybil e motivar os Bookies a cumprir as suas obrigações e garantir o bom funcionamento do sistema.

No sistema Book, a gestão da identidade e da reputação é fundamental, com inovações que incluem:

• Cada identidade anónima corresponde a uma reputação que reflecte a sua probabilidade histórica de liquidação, mantendo a privacidade da identidade.

• Os comerciantes podem definir limites de reputação para filtrar as contrapartes de correspondência de ordens, garantindo a segurança e a fiabilidade das transacções.

• Os comerciantes que não efectuarem a liquidação receberão penalizações de reputação, afectando também a reputação dos seus homólogos de negociação.

Por exemplo, suponha que Alice quer comprar 1 ETH,

• Submissão da ordem: Alice submete uma ordem para comprar 1 ETH a um preço especificado de $2000 USDT.

• Correspondência de ordens: O sistema Book encontra um vendedor, Bob, disposto a vender 1 ETH a $2000 USDT.

• Confirmação da transação: Alice e Bob confirmam que as suas encomendas foram correspondidas com sucesso.

• Liquidação da transação: Alice paga a Bob $2000 USDT e recebe 1 ETH. O sistema Singularity actualiza os saldos das suas contas.

• Gestão da reputação: Se Bob não completar a transação a tempo ou apresentar outros comportamentos negativos, a sua reputação pode ser reduzida, levando o sistema a restringir a sua correspondência com outros comerciantes. Se a classificação da reputação do Bob for 5, isso indica que ele é um negociante fiável. No entanto, se não conseguir concluir a transação a tempo ou se tiver outros comportamentos negativos, como cancelar ordens várias vezes ou manipular o mercado de forma maliciosa, a sua reputação pode ser afetada. Isto pode levar a uma diminuição de 1 ponto no seu índice de reputação para 4, limitando ainda mais o seu limiar de participação em futuras negociações.

1. Automatização

O Automation é um AMM-DEX integrado no protocolo, com o Book a atuar como um fornecedor alternativo de liquidez. Uma vez que os comerciantes podem submeter transacções através da Singularity para depositar fundos, e a Singularity é anónima, os depósitos na Automation também são anónimos. Isto significa que as identidades dos comerciantes não são expostas, protegendo a sua privacidade.

Os comerciantes podem retirar fundos do Automation em qualquer altura e transferi-los para o contrato Singularity. Esta flexibilidade permite aos comerciantes gerir livremente os seus fundos e retirá-los sempre que necessário. Do mesmo modo, uma vez que o próprio contrato Singularity é anónimo, o processo de levantamento também mantém o anonimato dos comerciantes.

Para ordens que não podem ser correspondidas com quaisquer ordens no livro, a automatização fornecerá correspondência para ajudar a aumentar a liquidez. Isto garante que, mesmo que as ordens não sejam imediatamente correspondidas, as ordens dos comerciantes podem ser processadas e as suas transacções podem continuar. Ao fornecer liquidez adicional, a automatização melhora a eficiência global e a experiência de negociação do protocolo.

1. Relayer

Na Singularity, o Relayer desempenha um papel crucial, sendo responsável pela apresentação de meta-transacções em nome dos utilizadores e pelo pagamento da taxa de gás para as transacções dos utilizadores. Esta conceção é motivada pelo desejo de proteger o anonimato do utilizador. Uma vez que as taxas de gás devem ser pagas à blockchain de base tipicamente pública, se os utilizadores pagassem as suas próprias taxas de gás, as suas identidades poderiam ser potencialmente expostas.

Os retransmissores executam esta tarefa submetendo meta-transacções. As meta-transacções são nativamente verificáveis e computáveis, impedindo os retransmissores de adulterar ou alterar o conteúdo das transacções, garantindo assim a segurança e a integridade das transacções. Além disso, para evitar comportamentos maliciosos por parte dos retransmissores, o sistema foi concebido com uma rede de retransmissores sem confiança. Isto significa que qualquer pessoa pode gerir um Relayer sem ter de fornecer qualquer tipo de garantia.

As transacções apresentadas pelos utilizadores e as taxas associadas são públicas e serão pagas aos Relayers para os compensar pelas taxas de gás que cobrem. Esta conceção faz com que a rede Relayer seja um sistema racional, onde aceitará e submeterá quaisquer transacções lucrativas. Mesmo que existam retransmissores maliciosos, a presença de pelo menos um retransmissor honesto garante a integridade do sistema. É claro que os comerciantes têm a opção de gerir o seu próprio Relayer e substituir a Taxa de Gás, embora à custa de alguma privacidade.

1. API

A API serve de nó de interface para os utilizadores interagirem com o protocolo. Através da API, os utilizadores podem gerar e submeter provas ao contrato Singularity, gerir encomendas no Livro, ouvir o Livro para encontrar correspondências e negociar acordos no contrato Singularity. Além disso, a API permite que os utilizadores interajam com os retransmissores.

Transacções de privacidade

Com base na estrutura acima referida, podem ser implementadas as transacções de privacidade mencionadas anteriormente:

• Transacções anónimas (automatização)

Ao realizar transacções com a Automation, uma vez que os comerciantes têm de efetuar uma operação de depósito, o montante de dinheiro prometido de cada vez será exposto, tal como cada depósito na Singularity não pode evitar ser ouvido por terceiros que escutam os detalhes da transação. Por conseguinte, a realização de transacções através da automatização sacrificará a ocultação da transação.

Note-se que, quando o Book não consegue fazer corresponder um negociante, embora a sua ordem possa ser incluída no pool de negociação de automatização para correspondência (o que parece expor o endereço do negociante), o anonimato do negociante continua a ser assegurado, porque a entidade que transfere a sua liquidez é a Singularity.

• Transacções anónimas e ocultas (liquidação através da Singularidade)

Ao liquidar transacções através da Singularity, independentemente da forma como a descoberta do preço da transação e a correspondência de intenções são conduzidas, a liquidação final da transação pode ainda garantir o seu anonimato e ocultação. Isto deve-se ao facto de o contrato Singularity ser responsável pela liquidação da custódia dos fundos e pela transferência final dos mesmos, conseguindo assim visibilidade em aberto enquanto opera na obscuridade.

Negociação em Dark Pool: A implementação da Singularidade

Processo de negociação da Singularity

Uma dark pool, destinada a grandes instituições e a operadores profissionais, proporciona uma plataforma de negociação sem afetar os preços de mercado. Acomoda principalmente dois tipos de necessidades de negociação: Transferência e Swap. A seguir, vamos detalhar como a Singularity implementa estes dois tipos de transacções com base no conteúdo representado no diagrama acima. É importante notar que os nós API e os nós de negociação fazem parte do mesmo nó no diagrama; para maior clareza, são aqui descritos como dois tipos diferentes de nós.

1. Transacções de transferência

As transacções de transferência ocorrem principalmente entre dois nós do Comerciante. Definimos o nó do Operador recetor como Operador A e o nó do Operador emissor como Operador B. O processo específico para uma transação entre o Operador A e o Operador B é o seguinte:

1) Ao efetuar uma transação, o comerciante B deve depositar fundos no contrato Singularity. O comerciante B encripta esta transação de depósito chamando uma API, gerando assim uma prova ZK, também designada por nota ZK, e fornece-a ao contrato Singularity para verificar se o comerciante B depositou os fundos.

2) Depois de depositar os fundos, o comerciante B inicia uma transação de transferência chamando uma API para enviar uma nota ZK para o contrato Singularity.

3) Ao receber a Nota do Negociador B, o contrato Singularity identifica o Negociador A correspondente com base nas informações fornecidas na Nota. Nesta altura, o Negociador A pode extrair o montante da transação de Transferência do contrato Singularity.

Neste processo, observamos que a interação entre os nós e o contrato é realizada através de ZK Notes. As notas utilizam um modelo UTXO para a transferência, que possui inerentemente um grau de privacidade e anonimato em comparação com o modelo de conta. Este método garante que as especificidades de uma transação são conhecidas apenas pelo seu iniciador, enquanto externamente, parece que algum endereço interagiu com o contrato Singularity. No entanto, os dados básicos da transação, como o endereço do destinatário ou o montante da transação, não podem ser captados.

1. Transacções de swaps

Em comparação com as transacções de transferência, as transacções de swap são um pouco mais complexas devido à necessidade de encontrar uma contraparte de negociação. Aqui, definimos o nó Negociador que pretende participar numa transação de Swap como Negociador C e o nó Negociador do parceiro comercial eventualmente encontrado como Negociador D. O processo de transação específico entre o Negociador C e o Negociador D é o seguinte:

1) À semelhança do primeiro passo da transação de Transferência, o Operador C necessita de depositar fundos no contrato Singularity e, simultaneamente, o Operador C iniciará uma transação de Ordem para o nó Book chamando uma API.

2) Actuando como um nó de registo de encomendas fora da cadeia, o nó de registo tenta fazer corresponder diferentes transacções de encomendas num ambiente de encriptação totalmente homomórfica (FHE) sem conhecer os detalhes específicos das transacções de encomendas.

a. Se a correspondência for bem sucedida, o nó Book notificará os dois nós Trader correspondentes para que prossigam com a transação.

b. Se a correspondência falhar, o Livro depositará os fundos relacionados com esta transação na Automatização na cadeia como liquidez reservada. É o mesmo que depositar o seu dinheiro numa poupança como a Yu'e Bao. Se ainda houver transacções que não coincidam mais tarde, será dada prioridade à negociação a partir da automatização. Só quando os fundos em Automação forem insuficientes para completar a transação é que irá interagir com DEXs externas como a Uniswap através do contrato Singularity.

Depois de encontrar a contraparte comercial e negociar os detalhes do Swap, os comerciantes assinarão mutuamente os detalhes da transação de Swap. Depois, qualquer uma das partes pode utilizar estas assinaturas para construir uma prova de conhecimento zero, permitindo que a transação altere a propriedade das notas sem que ambas as partes estejam online. É importante notar que, para proteger a privacidade da transação, as transacções de Swap continuam a ser conduzidas através do contrato Singularity.

Assim, podemos ver que a Singularity utiliza principalmente as tecnologias ZK (Zero Knowledge) e FHE no processo de transação para alcançar a privacidade e o anonimato. A utilização da tecnologia ZK garante que as especificidades de qualquer transação só são conhecidas pelo iniciador, mas permite que outros comerciantes ou o contrato Singularity a verifiquem rapidamente; a tecnologia FHE permite que o nó Book calcule transacções mutuamente correspondentes durante o processo de correspondência sem precisar de conhecer os detalhes específicos das transacções, e também mantém as informações originais da transação confidenciais ao notificar ambas as partes, o que significa que as partes só sabem com quem estão a negociar, mas não o tipo de ativo específico e o montante da transação.

Resumo e avaliação

O mercado OTC representa cerca de 70% do volume de transacções de todo o mercado de criptomoedas, o que realça a procura significativa de transacções de privacidade na indústria Web3. No entanto, o sector do comércio da privacidade continua a enfrentar vários desafios, como o cumprimento dos requisitos regulamentares dos organismos governamentais, a realização de transacções sem revelar informações específicas sobre os utilizadores e as transacções e a prevenção de acções maliciosas por parte das partes envolvidas no comércio. As dark pools descentralizadas, como a Singularity, representam uma solução inovadora que pode fornecer aos utilizadores níveis mais elevados de proteção da privacidade e resistência à censura através da utilização de tecnologias de privacidade e contratos inteligentes, reduzindo a dependência de entidades centralizadas. Estas plataformas suportam grandes transacções de forma anónima e podem integrar-se em serviços de conformidade para criar um ambiente de negociação descentralizado e em conformidade com a regulamentação.

Considerações fundamentais para o sector das piscinas escuras:

1. Arquitetura técnica: As provas de conhecimento zero (ZKP) e a computação multipartidária (MPC) são fundamentais para o sector das "dark pool", permitindo a verificação da validade das transacções sem revelar os detalhes das mesmas. Muitos dos protocolos actuais baseiam-se em grande parte ou na totalidade no MPC, que tem dois inconvenientes principais: baixa eficiência computacional e complexidade do protocolo. Os protocolos MPC requerem a prova e verificação de ZKPs num quadro MPC, o que é computacionalmente intensivo. Além disso, o MPC necessita frequentemente de ligações de rede estáveis, o que é difícil de conseguir numa rede global descentralizada. Estes factores tornam os protocolos baseados inteiramente no MPC impraticáveis para aplicações de grande escala, como os motores de correspondência de encomendas.

2. Anonimato e proteção da privacidade : A regulamentação é um tema incontornável no sector da privacidade. Garantir o total anonimato das transacções e dos fundos e, ao mesmo tempo, proporcionar uma proteção suficiente da privacidade é uma tarefa difícil. É particularmente importante para os utilizadores que pretendem negociar com capital compatível. Os projectos de "dark pool" precisam urgentemente de integrar os processos KYB/KYC, adotar a regulamentação de forma proactiva e garantir que os dados KYC/KYB dos utilizadores não são divulgados para manter a legalidade da plataforma e a confiança dos utilizadores.

3. Liquidez & Segurança do Fundo : A liquidez é um fator crítico nas operações de dark pool. Assegurar um volume de negociação suficiente e a segurança dos fundos é vital para uma correspondência eficiente das ordens e para reforçar o anonimato e a vontade de participar dos operadores. Nas dark pools, o anonimato dos fundos aumenta com a dimensão da pool, tornando mais difícil o rastreio de depositantes específicos. Em cenários de escassa liquidez, os modelos de livro de ordens de muitos protocolos têm limitações na correspondência de transacções entre utilizadores, uma vez que podem nem sempre fornecer liquidez suficiente para todas as ordens. Para além dos livros de ordens, os mecanismos de negociação inovadores da AMM e a integração de mais aplicações DeFi de vários ecossistemas de cadeias de blocos poderão ser formas eficazes de expandir a liquidez.

4. Escalabilidade: Garantir uma boa escalabilidade para acomodar um número crescente de utilizadores e volumes de transacções é essencial para as dark pools. Os Dark Pools arriscam-se a sofrer perdas se se depararem com um aumento de LPs sem ordens correspondentes. Por conseguinte, as dark pools devem ter em conta as suas camadas de liquidação, a sua conceção técnica e o roteiro do ecossistema durante a fase de conceção, a fim de satisfazerem as exigências de transacções mais elevadas, especialmente no âmbito de quadros regulamentares progressivamente abrangentes.

A negociação em "dark pool", com um certo historial nas indústrias tradicionais e ainda por provar como solução, continua a ter uma procura significativa no mercado e um potencial de desenvolvimento. O comércio tradicional de dark pool enfrenta riscos de confiança com comerciantes centralizados, enquanto projectos descentralizados como o Singularity adoptam de forma inovadora um modelo de "dark pool + pool transparente para dark trades", abordando os pontos problemáticos da dependência da centralização, privacidade insuficiente e fraca resistência à censura.

Ao contrário de projectos anteriores de comércio de privacidade, a Singularity oferece uma funcionalidade de comércio de privacidade de activos juntamente com capacidades de comércio de activos DeFi. O mercado atual está repleto de agregadores de transacções, mas poucos têm características distintivas ou um design que aumente a adesão dos utilizadores. A Singularidade, servindo como uma camada de privacidade para pools transparentes, aborda em primeiro lugar os problemas de negociação das instituições e das baleias, mantendo a assimetria de informação. Em comparação com as actuais soluções de negociação com privacidade, a conceção de uma "dark pool" (camada de privacidade) incorpora naturalmente o princípio de "manter o dinheiro no bolso", uma vez que a privacidade se perde se os fundos dos operadores entrarem e saírem frequentemente da plataforma, o que equivale a uma auto-revelação. Assim, a maior parte dos fundos prefere permanecer na "dark pool" durante um período de tempo suficiente antes de proceder ao seu levantamento, o que beneficia o crescimento estável do projeto TVL e proporciona maior segurança aos utilizadores.

Com base nas normas acima mencionadas para dark pools descentralizadas, a Singularity destaca-se entre as actuais soluções de dark pool por várias razões:

• Anonimato e proteção da privacidade : Para o anonimato, a abordagem convencional é a prova de conhecimento zero (ZKP). Por isso, é fundamental encontrar os parceiros certos. Atualmente, a Singularity delega os processos KYC & KYB fora da cadeia ao ComplyCube (KYC) e ao Shufti Pro (KYC & KYB), sendo que o Keyring constrói as provas correspondentes e os oráculos acabam por trazer essas provas para a cadeia de blocos. Em comparação com outros projectos, a Singularity está mais em conformidade com os actuais requisitos de conformidade, evitando futuros riscos regulamentares semelhantes aos enfrentados pela Tornado Cash.

• Segurança dos fundos: Não é possível uma comparação direta da segurança dos contratos. No entanto, uma vez que a Singularity permite que os pools transparentes actuem como dark pools, pode diminuir a vontade dos utilizadores e das instituições de movimentar fundos, expondo potencialmente o seu capital a riscos de segurança contratual a longo prazo. Como já foi referido, as transferências frequentes de fundos pelas instituições/utilizadores podem também expor os endereços, exigindo assim um equilíbrio entre a privacidade dos endereços e a segurança dos fundos.

• Liquidez: Ao contrário dos projectos que se baseiam apenas em modelos de carteira de encomendas/AMM, a Singularity introduz tanto a carteira de encomendas como os AMM para maximizar a eficiência da liquidez. No entanto, a aplicação real pode mostrar que a diferença de liquidez devida aos modelos de negociação pode não ser significativa, dependendo mais das capacidades de desenvolvimento empresarial do projeto e da sua conformidade, ficando a decisão final em grande medida nas mãos dos utilizadores do mercado.

• Escalabilidade: Em termos de compatibilidade com o ecossistema, a compatibilidade da Singularity com o ecossistema EVM é uma narrativa corrente. Se não considerar a criação da sua própria cadeia, a sua eficiência de liquidação de transacções continua a ser altamente limitada pela sua camada de liquidação. Em casos extremos, estas camadas podem não ser capazes de lidar com transacções de elevada frequência. Por conseguinte, a médio e a longo prazo, os projectos que estendem a direção do ecossistema da cadeia de aplicações serão mais escaláveis. Tecnicamente, a Singularity opta pelo FHE+ZKP, que é mais eficiente do que as soluções MPC-ZKP devido à elevada eficiência computacional exigida pelo MPC-ZKP. Por conseguinte, a abordagem tecnológica escolhida pela Singularity parece satisfazer as necessidades da transação. Do ponto de vista da expansão do ecossistema, a abordagem "piscina transparente como piscina escura" pode estender-se a cenários não transaccionais e a outros contextos DeFi, oferecendo possibilidades imaginativas comparáveis às propostas pelo Uniswap V4 com ganchos.

Ao mesmo tempo que se reconhecem as principais competências da Singularity, é também importante estar consciente dos potenciais riscos que o projeto pode enfrentar no futuro:

• Perda da função de descoberta de preços de mercado: Devido ao anonimato e ao grande volume de transacções no dark pool, os preços dos activos no mercado podem não refletir com precisão as flutuações no dark pool. Isto resulta numa perda de descoberta efectiva de preços, uma vez que os outros participantes no mercado não podem aceder a informações sobre as transacções das dark pool. A exceção é se os utilizadores utilizarem DEXs convencionais para a descoberta de preços na Singularity, onde os preços podem refletir a oferta e a procura reais do mercado.

• Risco de regulamentação governamental : As transacções em Dark Pool, potencialmente utilizadas para fugir à regulamentação e às normas, podem levar as agências governamentais a implementar medidas regulamentares mais rigorosas. Estas poderiam incluir um melhor controlo e regulamentação das transacções de "dark pool" ou sanções para os indivíduos e entidades que participam nessas transacções. Estas medidas podem ter impacto no desenvolvimento e funcionamento do projeto Singularity e aumentar os riscos jurídicos.

• Controlo e segurança dos fundos: Com os fundos mantidos a longo prazo em contratos da Singularidade, semelhantes a um cofre, pode haver riscos contratuais em situações extremas. No entanto, uma vez que a Singularity não envolve comunicação em várias cadeias nem depende de retransmissores de transacções, a sua segurança é, pelo menos, superior à das pontes entre cadeias.

• Riscos KYC/KYB : A grande dependência de um número limitado de parceiros para as verificações de qualificação dos utilizadores pode introduzir pontos únicos de falha.

Em suma, a Eureka Partners considera a pista da privacidade como um investimento estratégico significativo. Para as instituições de investimento e outras partes interessadas, a Singularity representa uma "dark pool trading"; no entanto, para os reguladores, é mais parecida com uma "grey pool". Prevemos que as transacções OTC e institucionais adoptem gradualmente métodos de negociação regulamentados de privacidade em dark pool. Acreditamos que o atual desenvolvimento tecnológico da Web3 está a fazer um "progresso iterativo". Na sequência da regulamentação rigorosa da Tornado Cash, surgiu um vácuo visível na procura de comércio de privacidade. Historicamente, a aplicação das regras é muitas vezes mais lenta do que os avanços tecnológicos e as revoluções. Quando a tecnologia enfrenta desafios, devemos abraçar a mudança e não desperdiçar nenhuma crise. Esperamos que a Singularity se torne o próximo líder no sector da privacidade ZK do dark pool regulamentado.

"Nunca desperdice uma boa crise." - Winston Churchill

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso da Eureka Partners, Forward the Original Title'Eureka Partners Research Report: Singularity - Privacy Transactions on Transparent Blockchains',Todos os direitos de autor pertencem ao autor original[Oliver, Andy, Howe]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.