A partir da programação de aplicativos Bitcoin, uma explicação detalhada de 10.000 palavras sobre a programabilidade do CKB

O seguinte conteúdo foi reproduzido do fórum Nervos Talk, escrito por Ajian (editor-chefe da plataforma de conteúdo Bitcoin BTC Study).

Resumo

理解一个系统的可编程性要求我们辨识这个系统在结构上的特征。对基于比特币脚本的应用编程的探索，有助于我们理解 CKB Cell 的基本结构及其编程范式。不仅如此，它还能将 CKB 的编程元件分解为恰当的部分，并帮助我们理解每一部分所带来的可编程性增益。

1. Introdução

"Programabilidade" é uma dimensão frequentemente considerada ao comparar sistemas de blockchain. No entanto, existem diferentes formas de descrever a programabilidade. Uma descrição comum é que "A blockchain XX suporta uma linguagem de programação Turing Completo" ou "A blockchain XX suporta programação geral", o que implica que a blockchain XX possui uma alta capacidade de programabilidade. Essas afirmações têm algum mérito: sistemas que suportam programação Turing Completo geralmente são mais fáceis de programar do que aqueles que não suportam. No entanto, as características estruturais de um sistema de contratos inteligentes têm muitos aspectos, e essa afirmação aborda apenas um deles. Portanto, não é suficiente para obter uma compreensão profunda: os desenvolvedores não podem obter orientações a partir disso, e os usuários regulares não podem usá-lo para distinguir fraudes.

O sistema de contratos inteligentes tem as seguintes características estruturais:

• Forma básica de expressão de estado (conta vs. saída de transação)
• Se permite cálculos de programação arbitrários ("Turing Completo" é sobre isso).
• 过程 de execução pode criar novos dados ou apenas retornar um valor booleano? (computação vs. verificação)
• 是否允许在合约内记录额外的状态 -> * É permitido registrar um estado adicional dentro do contrato
• Se um contrato pode acessar o estado de outro contrato durante a execução.

Portanto, além da "capacidade de programar qualquer cálculo", existem pelo menos mais quatro aspectos que afetam a programabilidade de um sistema de contrato inteligente. Pode-se até dizer que esses outros aspectos são mais importantes, pois determinam mais profundamente o que é fácil de realizar, o que é difícil de realizar; o que é economicamente viável de realizar e o que é ineficiente de realizar.

"Por exemplo, as pessoas frequentemente usam o Ethereum como um exemplo de boa programabilidade, mas a forma básica de expressar o estado do Ethereum é através de contas, o que torna difícil programar contratos ponto a ponto (como canais de pagamento, contratos de aposta um a um) - não é impossível de ser feito, mas é complicado e pouco prático. O ecossistema do Ethereum não é estranho a projetos que tentaram implementar canais de pagamento/estado e também há muitas discussões teóricas, mas até agora esses projetos parecem estar inativos - isso claramente não é culpa dos desenvolvedores. Atualmente, os projetos ativos no Ethereum adotam a forma de "pool de fundos" em vez de contratos ponto a ponto, e isso não é por acaso. Da mesma forma, as pessoas podem estar satisfeitas com a programabilidade do Ethereum no momento, mas se quisermos implementar uma "abstração de conta" (também pode ser entendida como uma generalização do conceito de carteira), o modelo de conta tem suas limitações inatas."

Da mesma forma, explorar a programabilidade do CKB exige que compreendamos as características estruturais do sistema de contratos inteligentes do CKB nesses aspectos. Já sabemos que o CKB permite a programação de qualquer cálculo, permite o registro de estados adicionais dentro do contrato e também permite que um contrato acesse o estado de outro contrato durante a execução. No entanto, a forma do contrato é a saída da transação, chamada de "Cell", o que cria diferenças fundamentais em relação ao Ethereum. Portanto, entender o sistema de contratos inteligentes do Ethereum e os exemplos de contratos nele não nos ajuda a compreender como o CKB implementa essas características estruturais, nem nos ajuda a entender a programabilidade do CKB.

幸运的是，Bitcoin的contratos inteligentes似乎为我们理解 CKB 的可编程性提供了最好的基础。这不仅是因为Bitcoin的状态表达的基本形式也是交易的输出（称为 “UTXO”），更是因为，借助Bitcoin社区提出的一个概念 “限制条款（covenants）”，我们可以理解 CKB 具备上述结构特性的原因，并将最终的效果恰当地分拆成几个部分、逐一辨识它们所带来的可编程性增益。

二. CKB v.s. BTC: O que há de diferente?

Estrutura básica

作为比特币状态表达的基本形式，比特币的 UTXO（“未花费的交易输出”）有两个字段：

• O valor, em satoshis, representa o valor em bitcoin que a UTXO possui;
• Chave pública de script, também conhecida como script de bloqueio, representa as condições necessárias para gastar esses fundos, ou seja, o programa de contrato inteligente que define as condições para desbloquear esses fundos.

与后来出现的Contrato inteligente系统相比，比特币脚本是相当受限的：

• Não permite cálculos de programação arbitrários; apenas alguns cálculos práticos são possíveis de serem verificados (verificação de assinatura, verificação de imagem de hash, verificação de tempo)
• Não permite registrar um estado adicional dentro do contrato; (por exemplo, você não pode usar um script para limitar o limite/proporção de gastos únicos; também não pode esconder uma token dentro dele)
• Também não permite o acesso ao estado de outro contrato durante a execução (cada script é um universo independente e não dependente um do outro).

Esta linguagem de script pode ser limitada, mas não falta a capacidade de criar aplicações surpreendentes. Além disso, é exatamente a base para explorar a programabilidade do CKB. No próximo capítulo, serão apresentados dois exemplos de programação de scripts do Bitcoin.

Em contraste, a unidade de estado do CKB é chamada de "Cell" e possui quatro campos.

• Capacidade, semelhante ao valor da UTXO, indica o tamanho do espaço que uma célula pode ocupar, em bytes.
• Lock, semelhante à chave pública do script UTXO, define a propriedade desta célula; somente os dados fornecidos podem ser "atualizados" por meio do Lock, permitindo "liberar" essa célula e cunhar novas células usando essa capacidade.
• Dados, dados, quaisquer dados, cujo volume é limitado pela capacidade;
• Tipo ，script opcional para definir condições para atualizar os dados.

Além disso, Lock e Type também podem ser programados para cálculos arbitrários. Você pode programar qualquer algoritmo de verificação de assinatura e também pode programar verificações de imagem inversa para qualquer algoritmo de hash, e assim por diante.

Leitores podem facilmente perceber a melhoria da capacidade de programação do Cell em comparação com o UTXO.

• Cell pode programar qualquer tipo de cálculo, em vez de apenas programar alguns cálculos específicos; sua verificação de propriedade será mais flexível;
• Devido aos campos Data e Type, o Cell pode registrar estados adicionais; isso permite que o Cell transporte o chamado "UDT (Token Personalizado do Usuário)".

Combine the "transaction output" structure of Cell itself, the benefits that these two points can bring are already very, very huge. However, only from the description above, we don't yet know how Cell implements "accessing the state of another contract during runtime". For this, we need to rely on a concept that the Bitcoin community has been discussing for a long time: "covenants".

Termos Restritivos e Auto-reflexão

A intenção das cláusulas de restrição é limitar para onde um determinado valor pode ser gasto. No Bitcoin atual (que ainda não implementou nenhuma proposta de cláusulas de restrição), uma vez que um valor é desbloqueado, ele pode ser gasto em qualquer lugar (pode ser pago para qualquer chave pública de script). No entanto, a ideia das cláusulas de restrição é poder limitar o gasto desse valor apenas para determinados destinos. Por exemplo, uma UTXO só poderia ser gasto por uma transação específica, mesmo que alguém possa fornecer uma assinatura para essa UTXO, o destino para onde ela pode ser gasta já está definido por essa transação. Essa funcionalidade parece um pouco estranha, mas pode gerar algumas aplicações interessantes, que serão abordadas em uma seção posterior. O importante é que isso é fundamental para entendermos a programabilidade do CKB.

Rusty Russell corretamente apontou que as cláusulas de restrição podem ser entendidas como a capacidade de "introspecção" das transações, ou seja, quando uma UTXO A é gasta por uma transação B, o programa de script pode ler parte (ou a totalidade) da transação B e verificar se elas são consistentes com os parâmetros exigidos pelo script. Por exemplo, se a chave pública do primeiro output da transação A é consistente com a chave pública exigida pela UTXO A (esse é o significado original das cláusulas de restrição).

Leitores atentos perceberão que, se tiverem a capacidade de introspecção completa, poderão ler o estado de uma entrada de transação a partir de outra entrada da mesma transação, o que realiza a habilidade mencionada anteriormente de "acessar o estado de um contrato em execução de outro contrato". Na verdade, a CKB Cell foi projetada dessa maneira.

基于此，我们又可以将这种完全的内省能力分成四种情形：

• Bloquear lendo outros blocos (entrada e saída)
• Lock 读取其它（输入和输出）的 Type （以及 Data）
• Tipo 读取其它（输入和输出）的 Lock
• Tipo leia outros (entrada e saída) Tipo (e Dados)

这 permite-nos analisar a capacidade de introspeção de cada parte em diferentes cenários de aplicação, sob a premissa de certas funções distintas de Bloqueio e Tipo, ou seja, analisar os ganhos de programabilidade que cada parte nos traz em diferentes contextos de aplicação.

Nos dois capítulos a seguir, vamos aprender sobre a programação de scripts do Bitcoin atual (proposta de termos não restritos) e as possibilidades que a proposta de termos restritos traz, a fim de entender melhor como programar e melhorar as células CKB.

3. Programação de Script Bitcoin

本节将使用 “Rede de iluminação” e “Contrato de Log de Cautela (DLC)” 作为基于比特币脚本的应用编程的案例。在展开之前，我们要先了解两个概念。

OP_IF e "transações de compromisso"

O primeiro conceito são os códigos de operação de controle de fluxo no script do Bitcoin, tais como: OP_IF, OP_ELSE. Estes códigos de operação não diferem muito do "IF" na programação de computadores, sua função é executar diferentes declarações com base em diferentes entradas. No contexto do script do Bitcoin, isso significa que podemos definir vários caminhos de desbloqueio para os fundos; juntamente com a característica de bloqueio de tempo, isso significa que podemos atribuir prioridade de ação.

Usando o famoso contrato de bloqueio de tempo com hash (HTLC) como exemplo, esse script pode ser traduzido em linguagem simples como:

Ou, Bob pode revelar uma imagem original por trás de um valor de hash H e fornecer sua assinatura para gastar esses fundos;

或者, Alice pode gastar esses fundos com sua própria assinatura após um período de tempo T.

Esta "ou...ou..." efeito é alcançado através do código de operação de controle de fluxo.

HTLC tem a vantagem mais proeminente de poder agrupar várias operações juntas e alcançar a atomicidade. Por exemplo, Alice quer trocar BTC por CKB com Bob, então Bob pode primeiro fornecer um valor de hash e criar um HTLC na rede Nervos; em seguida, Alice cria um HTLC no Bitcoin usando o mesmo valor de hash. Ou Bob leva o BTC pago por Alice no Bitcoin e revela o segredo, permitindo que Alice pegue o CKB na rede Nervos. Ou Bob não revela o segredo, ambos os contratos expiram e Alice e Bob podem recuperar seus fundos investidos.

Após a ativação da bifurcação suave Taproot, essa característica de caminhos de desbloqueio múltiplos é fortalecida ainda mais com a introdução do MAST (Merkle Abstract Syntax Tree): podemos transformar um caminho de desbloqueio em uma folha da árvore de Merkle, onde cada folha é independente, portanto, não é mais necessário usar códigos de operação de controle de fluxo desse tipo; além disso, como revelar um caminho não expõe os outros caminhos, podemos adicionar mais caminhos de desbloqueio a uma saída sem nos preocuparmos com problemas de eficiência.

O segundo conceito é "transação de promessa". A ideia de uma transação de promessa é que, em algumas situações, uma transação de Bitcoin válida e vinculativa pode ser considerada verdadeira, mesmo que não tenha sido confirmada na blockchain.

Por exemplo, Alice e Bob compartilham a posse de um UTXO que requer a assinatura de ambos para ser gasto. Nesse caso, Alice cria uma transação para gastá-lo, transferindo 60% de seu valor para Bob e o restante para si mesma; Alice assina a transação e a envia para Bob. Assim, para Bob, não é necessário transmitir essa transação para a rede Bitcoin, nem garantir sua confirmação na blockchain, pois o efeito de pagamento é legítimo e confiável. Isso ocorre porque Alice não pode gastar o UTXO sozinha (portanto, não pode gastá-lo novamente) e a assinatura fornecida por Alice é válida, permitindo que Bob adicione sua própria assinatura a qualquer momento e transmita a transação para realizar o pagamento. Em outras palavras, Alice forneceu a Bob um "compromisso confiável" por meio dessa transação válida (não confirmada na blockchain).

承诺交易是Bitcoin应用编程的核心概念。如前所述，Bitcoin的合约是基于验证的、无状态的、不允许交叉访问的；但是，如果合约不携带状态，那这些状态存放在哪里、合约如何安全推进（变更状态）？承诺交易给出了直截了当的答案：合约的状态可以用交易的形式来表达，从而，合约的参与者可以自己保存状态，而不必将它们展现在区块链上；合约的状态变更问题，也可以转化成如何安全地更新承诺交易的问题；此外，如果我们担心进入一个合约会有危险（例如，进入一个要求双方都签名才能花费的合约，会面临对方不响应从而卡死的风险），那么，只需提前生成花费该合约的承诺交易并获得签名，就可以化解风险、消除对其他参与者的信任。

Rede de canais de troca instantânea e Rede de iluminação

闪电通道是一种一对一的合约，在这种合约中，双方可以无限次地相互支付，而不必让任何一次支付获得区块链的确认。如你所料，它用到了承诺交易。

Na parte em que explicamos a "transação de promessa", já introduzimos um tipo de canal de pagamento. No entanto, este contrato de pagamento que utiliza apenas 2-of-2 assinaturas múltiplas só pode realizar pagamentos unidirecionais. Ou seja, ou é sempre Alice a pagar a Bob, ou é sempre Bob a pagar a Alice, até que o saldo no contrato esteja esgotado. Se for um pagamento bidirecional, isso significa que, após uma atualização de estado, o saldo de uma das partes pode diminuir, mas ela ainda possui a transação de promessa anterior assinada pela outra parte - há alguma maneira de impedir que ela transmita a antiga transação de promessa e só possa transmitir a mais recente transação de promessa?

Relâmpago é a solução para esse problema, chamada "LN-Penalty". Agora, suponha que Alice e Bob tenham 5 BTC cada em um canal. Agora, Alice quer pagar 1 BTC a Bob, então ela assina uma transação de compromisso como essa e a envia para Bob:

Digite #0, 10 BTC: Saída multiassinada Alie-Bob 2-de-2 (ou seja, contrato de canal)

"Output #0, 4 BTC: Alice single signature"

Saída #1, 6 BTC: ou Alice-Bob usa a chave pública temporária conjunta #1 para assinar sozinho, ou Bob assina sozinho com o bloqueio de tempo T1.

Bob também assina um compromisso de transação (correspondente à transação acima) e envia para Alice:

Digite #0, 10 BTC: Saída multi-assinada Alie-Bob 2-de-2 (ou seja, contrato de canal)

Enviar #0,6 BTC: Bob assinatura única

Saída #1, 4 BTC: ou Bob-Alice usando a chave pública temporária #1 com assinatura única, ou T1 com bloqueio de tempo, Alice com assinatura única.

Aqui está a chave, é a "Chave Pública Temporária Conjunta". É gerada usando a chave pública da parte própria e a chave pública fornecida pela outra parte. Por exemplo, a chave pública temporária conjunta de Alice-Bob é calculada pela multiplicação e adição das chaves públicas individuais de Alice e Bob com um valor de hash. Durante a geração dessa chave pública, ninguém sabe sua chave privada. No entanto, se Bob revelar a chave privada da chave pública fornecida, Alice poderá calcular a chave privada dessa chave pública conjunta. - Esta é a chave para "reverter" o estado antigo do canal de pagamentos.

在 próxima atualização do canal (iniciar pagamento), as duas partes trocam as chaves privadas temporárias entregues na última rodada. Dessa forma, os participantes não se atrevem a transmitir a transação de promessa anterior que receberam: a saída que aloca valor para si tem dois caminhos, e a chave privada do caminho da chave pública temporária já é conhecida pela outra parte. Portanto, uma vez que a transação de promessa antiga for transmitida, a outra parte poderá imediatamente usar essa chave privada temporária conjunta para pegar todo o dinheiro desta saída. - Este é o significado de "LN-Penalty".

具mente, a sequência de interação é a seguinte: a parte que inicia o pagamento primeiro solicita uma nova chave pública temporária à outra parte e, em seguida, constrói uma nova transação de compromisso e a entrega à outra parte; a parte que recebe a transação de compromisso expõe à outra parte a chave privada da chave pública temporária fornecida na rodada anterior. Essa sequência de interação garante que os participantes sempre recebam primeiro a nova transação de compromisso e, em seguida, invalidem a transação de compromisso recebida na rodada anterior, portanto, é livre de confiança.

Em resumo, os principais designs-chave do canal relâmpago são:

As duas partes sempre usam transações de compromisso para expressar o estado interno do contrato e representam o pagamento através de mudanças de valor.

承诺交易总是花费同一个输入（需要双方同时提供签名的输入），因此所有承诺交易都是相互竞争的，最终只有一笔能够得到区块链的确认；

Dois participantes não assinam a mesma transação de compromisso (embora sejam em pares); em vez disso, eles sempre assinam transações que são mais favoráveis a si mesmos, ou seja, os participantes sempre recebem transações de compromisso que são desfavoráveis a si mesmos;

Esta desvantagem é refletida no fato de que a saída que atribui valor a si mesma tem dois caminhos de desbloqueio: um caminho pode ser desbloqueado com a assinatura própria, mas requer um tempo de espera; enquanto o outro caminho usa a chave pública do destinatário, e só está protegido se a chave privada temporária não for exposta.

Em cada pagamento, ambas as partes trocam as chaves privadas temporárias que foram usadas na transação anterior, através de uma nova transação de compromisso. Dessa forma, a parte que entrega a chave privada temporária não se atreve a transmitir a transação de compromisso anterior, "revogando" assim a transação de compromisso anterior e atualizando o estado do contrato. (Na verdade, essas transações de compromisso são todas válidas e podem ser transmitidas para a cadeia de blocos, mas os participantes não se atrevem a fazê-lo devido à punição.)

Qualquer uma das partes pode sair do contrato a qualquer momento, desde que a outra parte tenha assinado o compromisso de transação de saída. No entanto, se ambas as partes estiverem dispostas a cooperar, elas podem assinar uma nova transação, permitindo que ambas as partes recuperem imediatamente seu próprio dinheiro.

Finalmente, como as transações HTLC também podem ser inseridas em promessas de transação, os canais de raio também podem encaminhar pagamentos. Suponha que Alice possa encontrar um caminho composto por canais de raio consecutivos que cheguem a Daniel, então, é possível realizar pagamentos de várias etapas sem a necessidade de abrir um canal com Daniel. Isso é a Rede de iluminação.

Alice - HTLC -> Bob - HTLC -> Carol - HTLC -> Daniel

Alice <-- image -- Bob <-- image -- Carol <-- image -- Daniel.

Quando Alice descobre esse caminho e deseja pagar a Daniel, ela solicita a Daniel um valor de hash para construir um HTLC para Bob e pede a Bob que encaminhe uma mensagem para Carol e forneça o mesmo HTLC. A mensagem instrui Carol a encaminhar a mensagem para Daniel e fornecer o mesmo HTLC. Quando a mensagem chega a Daniel, ele revela o pré-imagem para Carol, obtendo assim o valor do HTLC e atualizando o estado do contrato. Carol faz o mesmo, recebe o pagamento de Bob e atualiza o estado do canal. Por fim, Bob revela a pré-imagem para Alice e atualiza o estado. Devido às características do HTLC, esses pagamentos em cadeia são bem-sucedidos juntos ou falham juntos, tornando-os confiáveis.

A Rede de iluminação é composta por uma série de canais, sendo cada canal (contrato) independente. Isso significa que a Alice só precisa estar ciente do que acontece no canal entre ela e o Bob, sem se preocupar com as interações nos canais de outras pessoas, nem com a moeda utilizada nessas interações, ou mesmo se elas realmente ocorreram).

A escalabilidade da Rede de iluminação não se limita apenas à velocidade de pagamento dentro de um canal de iluminação, que é restrita apenas pelos recursos de hardware das partes envolvidas. Também está relacionada ao fato de que, devido ao armazenamento descentralizado do estado, um único nó pode alavancar a maior alavancagem com o menor custo.

Contrato de registro cauteloso

O contrato financeiro discreto (DLC) cauteloso utiliza uma técnica criptográfica chamada "assinatura do adaptador" para permitir que scripts de Bitcoin programem contratos financeiros dependentes de eventos externos.

Adaptador de assinatura permite que uma assinatura só se torne válida após a adição de uma chave privada. Tomando a assinatura Schnorr como exemplo, a forma padrão de uma assinatura Schnorr é (R, s), onde:

R = r.G # O valor nonce r multiplicado pelo ponto gerado da curva elíptica, também pode ser chamado de chave pública de r.

s = r + Hash(R || m || P) \* p # p is the private key for signing, P is the public key.

Verificar a assinatura significa verificar que s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK

假设我给出了一对数据(R, s')，其中：

R = R1 + R2 = r1.G + r2.G

s' = r1 + Hash(R || m || P) * p

Obviamente, esta não é uma assinatura Schnorr válida, pois não passa na fórmula de verificação. No entanto, posso provar aos validadores que, se eles conhecerem a chave privada r2 de R2, ela pode ser transformada em uma assinatura válida.

s'.G + R2 = R1 + Hash(R || m || P) * P + R2 = R + Hash(R || m || P) * P

A assinatura do adaptador torna a validade de uma assinatura dependente de dados secretos e é verificável. Mas qual é a relação disso com contratos financeiros?

假设 Alice e Bob querem apostar no resultado de um jogo. Alice e Bob apostam que o Green Magic e o Arinna vencerão, com uma aposta de 1 BTC. Além disso, o site de avaliação esportiva Carol promete assinar o resultado com um nonce R_c e publicar a assinatura s_c_i quando o resultado do jogo for revelado.

Pode-se ver que existem três possíveis resultados (portanto, a assinatura de Carol tem três possibilidades):

• O Green Wizard vence, Alice ganha 1 BTC
• Arina vence, Bob ganha 1 BTC
• Empate, os fundos de ambos retornam pelo mesmo caminho.

为此，两人为每一种结果创建一笔承诺交易。例如，他们为第一种结果创建的承诺交易是这样的：

Entrada #0, 2 BTC: Saída de Multisig 2-de-2 de Alie-Bob (ou seja, contrato de aposta)

Output #0, 2 BTC: Alice single signature

Mas as assinaturas criadas por Alice e Bob para esta transação não são (R, s), mas sim assinaturas do adaptador (R, s'). Ou seja, as assinaturas fornecidas por ambas as partes não podem ser usadas diretamente para desbloquear este contrato, sendo necessário revelar um valor secreto. Esse valor secreto é o preimagem de s_c_1.G, ou seja, a assinatura de Carol! Como o valor nonce da assinatura de Carol já está definido (é R_c), então s_c_1.G pode ser construído (s_c_1.G = R_c + Hash(R_c || 'Ethereum vence' || PK_c) * PK_c).

Quando os resultados forem revelados, supondo que o Green Magic vença, Carol publicará a assinatura (R_c, s_c_1). Portanto, tanto Alice quanto Bob podem completar a assinatura do adaptador do oponente, adicionar sua própria assinatura e tornar a transação válida, transmitindo-a pela rede e desencadeando a liquidação. Mas se o Green Magic não vencer, Carol não publicará s_c_1 e essa transação de compromisso não poderá ser válida.

Da mesma forma, as outras duas transações seguem o mesmo padrão. Assim, Alice e Bob tornam a execução deste contrato dependente de eventos externos (para ser preciso, dependente do relatório de eventos externos pelo oráculo, na forma de uma assinatura), e não precisam confiar na contraparte. Contratos financeiros de todos os tamanhos, como futuros e opções, podem ser implementados dessa forma.

Em comparação com outras formas de implementação, a característica mais marcante do contrato de log cauteloso é a sua privacidade: (1) Alice e Bob não precisam informar a Carol que estão usando os dados dela, isso não afeta a execução do contrato; (2) Os observadores na cadeia (incluindo Carol) também não conseguem determinar qual serviço online Alice e Bob estão usando através das transações do contrato, nem mesmo podem saber se o contrato deles é um contrato de aposta (em vez de um canal de pagamento rápido).

4. Introdução à Aplicação das Condições Restritivas

OP_CTV e Controle de Congestionamento

A comunidade de desenvolvedores do Bitcoin propôs várias propostas que podem ser classificadas como cláusulas restritivas. Atualmente, a proposta mais famosa é a OP_CHECKTEMPLATEVERIFY (OP_CTV), que é conceitualmente simples, mas mantém uma grande flexibilidade, sendo, portanto, bem recebida pela comunidade do Bitcoin, que valoriza a simplicidade. A ideia do OP_CTV é fazer uma promessa de um valor de hash no script, para restringir que esses fundos só possam ser gastos por transações representadas por esse valor de hash; esse valor de hash compromete as saídas da transação e a maioria dos campos, mas não compromete as entradas da transação, apenas compromete a quantidade de entrada.

""Controle de congestionamento" é um bom exemplo que pode demonstrar as características do OP_CTV. Seu cenário de aplicação básico é ajudar um grande número de usuários a sair de uma exchange (um ambiente de confiança) para um pool de fundos; como esse pool de fundos utiliza o OP_CTV para planejar os gastos futuros, ele pode garantir que os usuários possam sair desse pool de fundos sem confiança, sem a necessidade de ajuda de ninguém; e como esse pool de fundos se manifesta apenas como uma UTXO, evita o pagamento de altas taxas de transação quando a demanda por transações na cadeia aumenta (de n saídas para uma saída; e de n transações para uma transação). Os usuários dentro do pool podem oportunamente sair do pool novamente."

Digamos que Alice, Bob, Carol queiram retirar 5 BTC, 3 BTC e 2 BTC das trocas, respectivamente. Em seguida, exchange pode fazer uma saída de 10 BTC com 3 OP_CTV ramificações. Suponhamos que Alice queira retirar dinheiro, ela pode usar o ramo 1, e a transação representada pelo valor hash usado pelo OP_CTV desse ramo formará duas saídas, uma das quais é alocar 5 BTC para Alice; A outra saída, por sua vez, é um pool, que também usa OP_CTV para se comprometer com uma transação, permitindo que Bob tire apenas 3 BTC e envie os 2 BTC restantes para Carol.

Bob ou Carol também querem fazer um saque, o mesmo princípio se aplica. Ao fazer um saque, eles só podem usar transações que passam pela verificação OP_CTV correspondente, ou seja, só podem pagar a si mesmos a quantia correspondente e não podem sacar qualquer valor arbitrário. Os fundos restantes voltarão para um pool de fundos bloqueados com OP_CTV, garantindo que, independentemente da ordem de saque dos usuários, os usuários restantes possam sair do pool sem a necessidade de confiança.

抽象amente, o OP_CTV atua aqui para planejar o caminho da vida do contrato inteligente em direção ao término do contrato, garantindo que o contrato do pool de fundos aqui possa manter a propriedade de saída sem confiança, independentemente do caminho que siga ou do estado em que se encontre.

Esta OP_CTV também tem um uso muito interessante: "canal de pagamento unidirecional não revelado". Suponha que Alice forme um pool de fundos como este e garanta que os fundos possam ser retirados sem confiança para uma saída com o seguinte script:

要么，Alice和Bob一起花费它要么，一段时间后，Alice可以独自花费它

Se Alice não revelar a Bob, ele não saberá que essa saída existe; assim que Alice revelar a Bob, ele pode considerar essa saída como um canal de pagamento unidirecional com tempo limitado, Alice pode pagar imediatamente a Bob com esses fundos, sem precisar esperar pela confirmação na blockchain. Bob só precisa fazer a transação de promessa de Alice no blockchain antes que Alice possa gastá-la sozinha.

OP_Vault e Cofre

OP_VAULT é uma proposta de cláusula restritiva projetada especificamente para a construção de "contratos de cofres (vaults)".

O contrato do cofre visa ser uma forma mais segura e avançada de custódia autônoma. Embora os contratos de assinatura múltipla atuais possam evitar falhas pontuais de chaves privadas individuais, o proprietário da carteira ficará sem opções se um atacante realmente obtiver a quantidade de chaves privadas necessária. O cofre espera impor um limite de gastos único para os fundos; ao mesmo tempo, ao retirar fundos pelo caminho convencional, a operação de retirada será sujeita a um período de espera obrigatório; durante esse período de espera, a operação de retirada pode ser interrompida pelas operações de recuperação de emergência da carteira. Com um contrato assim, mesmo se for comprometido, o proprietário da carteira pode lançar operações de retaliação (usando um ramo de recuperação de emergência).

Em teoria, o OP_CTV poderia ser programado para este tipo de contrato, mas há muitas inconveniências, uma das quais é a taxa: ao comprometer a transação, ele também compromete a taxa a ser paga. Dado o propósito desse contrato, o intervalo de tempo para configurar o contrato e fazer saques será muito longo, tornando quase impossível prever a taxa adequada. Embora o OP_CTV não tenha restrição de entrada, portanto, pode-se aumentar a taxa aumentando a entrada, no entanto, as entradas fornecidas se tornarão integralmente a taxa, o que não é prático; outra maneira é CPFP, ou seja, gastar os fundos retirados para fornecer taxas em uma nova transação. Além disso, o uso do OP_CTV implica que tais contratos de cofre não podem ser sacados em lote (é claro que também não podem ser revertidos em lote).

OP_VAULT 提议则尝试通过提出新的操作码（OP_VAULT 和 OP_UNVAULT）来解决这些问题。OP_UNVAULT 是专为批量复原而设计的，我们暂时不提。OP_VAULT 的动作则是这样的：当我们把它放在脚本树的一个分支上时，它可以用来承诺一个可以动用的操作码（例如 OP_CTV）而不设具体的参数；在花费这个分支时，交易可以传入具体的参数，但不能更改其它分支。由此，它不必预设手续费，可以在花费这个分支时再设定手续费；假定这个分支也带有时间锁，那么它就会强制执行一个时间锁；最后，因为只可改变自身所在的分支，新的脚本树上的其它分支（包括紧急复原分支）不会被改变，因此允许我们打断这样的取款操作。

Além disso, há mais dois pontos que valem a pena mencionar: (1) A ação do código de operação OP_VAULT é semelhante a outra proposta de cláusula de restrição: OP_TLUV; Jeremy Rubin apontou corretamente que isso já gerou em certa medida o conceito de "cálculo": OP_TLUV/OP_VAULT compromete-se com um código de operação para permitir que um usuário passe parâmetros para esse código de operação por meio de uma nova transação, atualizando assim toda a árvore de script; isso já não é mais "verificar os dados inseridos com base em certas condições", mas sim "gerar novos dados significativos com base nos dados inseridos", embora o cálculo que pode ser ativado seja bastante limitado.

A proposta completa OP_VAULT também utiliza algumas propostas de política de mempool (como transações no formato v3) para obter melhores resultados. Isso nos lembra que o significado de "programação" pode ser mais amplo do que imaginamos. (Um exemplo semelhante é a Open Transaction na rede Nervos Network.)

五. Compreender CKB

Nas duas seções acima, discutimos como programar scripts interessantes em uma estrutura mais restrita (Bitcoin UTXO) e também apresentamos propostas para adicionar capacidades reflexivas a essa estrutura.

UTXO, embora tenha a capacidade de programar esses aplicativos, os leitores também podem perceber facilmente suas desvantagens ou áreas que podem ser otimizadas, como por exemplo:

• Em LN-Penalty, os participantes do canal devem manter um registro de todas as transações de compromisso anteriores e dos valores secretos de penalização correspondentes para lidar com a fraude do oponente, o que constitui um fardo de armazenamento. Se houver um mecanismo que garanta que apenas a transação de compromisso mais recente seja eficaz e que as transações de compromisso mais antigas sejam ineficazes, esse fardo pode ser eliminado e também pode eliminar o problema de os nós acidentalmente colocarem transações de compromisso mais antigas na cadeia devido a falhas e, portanto, serem penalizados acidentalmente.
• No DLC, assumindo que há muitos possíveis resultados para um evento, há também muitas assinaturas que precisam ser geradas com antecedência e entregues à outra parte, o que é uma grande carga. Além disso, os lucros do contrato DLC estão diretamente ligados à chave pública, portanto, a posição do contrato não é facilmente transferível. Existe alguma maneira de transferir a posição do contrato?

实际上，比特币社区已经为这些问题提出了答案，基本上跟一种 Sighash 提议（BIP-118 AnyPrevOut）有关。

Mas se estivermos programando em CKB, o BIP-118 estará disponível agora (podemos simular essa capacidade de marcação de Sighash usando introspecção e verificação de assinatura direcionada).

Ao estudar a programação do Bitcoin, não só aprendemos como programar no formato "saída de transação" (o que CKB pode programar), mas também como melhorar essas aplicações (como podemos usar a capacidade da CKB para melhorar as aplicações se as programarmos na CKB). Para os desenvolvedores da CKB, programar com base no script do Bitcoin é praticamente um material de estudo, e até mesmo um atalho.

Abaixo, analisaremos a programabilidade de cada módulo de programação do CKB em detalhes. Vamos primeiro considerar a capacidade de introspecção.

**Programabilidade de bloqueio de cálculo arbitrário **

Como mencionado acima, UTXO não pode ser programado para qualquer cálculo arbitrário. Por outro lado, o Lock pode ser programado para criar tudo baseado em UTXO (antes da implantação das cláusulas de restrição), incluindo, mas não se limitando aos canais de pagamento instantâneo e DLC mencionados anteriormente.

Além disso, essa capacidade de computação verificável permite que o Lock tenha mais opções de autenticação do que UTXO, tornando-o mais flexível. Por exemplo, podemos implementar um canal de pagamento rápido no CKB, onde uma parte usa assinatura ECDSA e a outra parte usa assinatura RSA.

Na realidade, este é um dos primeiros campos em que as pessoas começaram a explorar na CKB: usando essa capacidade flexível de autenticação de identidade para a custódia independente do usuário, alcançando assim a chamada "abstração de contas" - a autorização e o controle da validade da transação são muito flexíveis, quase sem restrições. Em princípio, isso combina "múltiplos ramos de gastos" com "meios de autenticação arbitrários". Exemplos de implementação incluem: Carteira JoyID, UniPass.

Além disso, Lock também pode realizar a proposta eltoo, o que significa que apenas a transação de compromisso mais recente precisa ser mantida no canal de pagamento da Lightning (na verdade, o eltoo pode simplificar todos os contratos ponto a ponto).

Programabilidade Tipo de Cálculo Arbitrário

Como mencionado acima, um dos principais usos do Type é programar UDT. Em combinação com o Lock, isso significa que podemos implementar canais de pagamento instantâneos baseados em UDT (bem como outros tipos de contratos).

Na verdade, a divisão entre Lock e Type pode ser considerada como uma atualização de segurança: Lock se concentra na implementação de métodos de custódia ou protocolos contratuais, enquanto Type se concentra na definição de UDT.

Além disso, a capacidade de iniciar verificações com base na definição do UDT permite que o UDT participe de contratos de forma semelhante ao CKB (UDT é um cidadão de primeira classe).

Aqui está um exemplo: Eu já propus um protocolo para garantia de empréstimo NFT sem confiança no Bitcoin. A chave para esse protocolo é uma transação comprometida, cujo valor de entrada é menor que o valor de saída (portanto, ela não é considerada uma transação válida). No entanto, assim que for fornecido valor de entrada suficiente para essa transação, ela se torna válida: uma vez que o mutuário possa fazer o pagamento, o credor não poderá tomar posse do NFT em garantia. No entanto, a natureza sem confiança dessa transação comprometida é baseada na verificação dos valores de entrada e saída do par de transações, então o mutuário só pode usar Bitcoin para o pagamento - mesmo que tanto o mutuário quanto o credor estejam dispostos a aceitar outra moeda (como USDT emitido pelo protocolo RGB), a transação comprometida do Bitcoin não pode garantir que, desde que o mutuário pague o valor total de USDT, ele possa recuperar seu próprio NFT, porque as transações de Bitcoin não têm conhecimento do estado do USDT! (Revisão: em outras palavras, não é possível construir uma transação comprometida com a condição de pagamento em USDT.)

Se pudermos realizar uma verificação com base na definição do UDT, podemos permitir que o mutuário assine outra transação de promessa que permita ao mutuário usar USDT para reembolsar o empréstimo. A transação verificará a quantidade de USDT de entrada e a quantidade de USDT de saída, proporcionando assim confiança zero para o usuário usar USDT como forma de pagamento.

Revisão: Supondo que os NFTs usados como garantia e os tokens usados para reembolso sejam emitidos usando o mesmo protocolo (como o RGB), o problema aqui pode ser resolvido. Podemos construir uma transação de compromisso com base no protocolo RGB, de modo que a transição de estado do NFT e o reembolso possam ocorrer simultaneamente (vinculando duas transições de estado em uma transação RGB). No entanto, a construção dessa transação de compromisso terá suas dificuldades, uma vez que as transações RGB também dependem das transações de Bitcoin. Em resumo, embora o problema possa ser resolvido, não é possível considerar o token como um cidadão de primeira classe.

接下来我们再考虑内省能力。

Bloquear leia outros bloqueios

Isso significa que, após a implementação da proposta de cláusulas restritivas, todas as possibilidades de programação na UTXO do Bitcoin serão afetadas. Isso inclui contratos de cofre mencionados anteriormente, bem como aplicativos baseados em OP_CTV, como controle de congestionamento.

XueJie mencionou um exemplo muito interessante: você pode implementar uma conta de recebimento em CKB, onde, ao usar essa conta como entrada para uma transação, se a conta de saída (usando a mesma trava) tiver uma capacidade maior, essa entrada não precisará de assinatura e não afetará a validade da transação. Na verdade, sem a capacidade de introspecção, essa conta não pode ser implementada. Essa conta de recebimento é muito adequada para ser usada como uma forma de recebimento para instituições, pois ela pode consolidar os fundos, embora sua privacidade seja comprometida.

Leia outros tipos s do bloqueio (juntamente com os dados)

Esta é uma aplicação interessante da capacidade - Token de ações. Lock decidirá com base na quantidade de Token em outras entradas se pode ou não usar sua própria capacidade e onde essa capacidade pode ser gasta (requer a capacidade de introspecção do Lock).

Tipo Leitura de outros bloqueios s

Não há certeza, mas pode-se assumir que é útil. Por exemplo, pode-se verificar nos tipos de dados se os bloqueios de entrada e saída das transações permanecem inalterados.

Leitura de outros tipos de Type Script (e Data)

集换卡？集齐 n 个 token 可以换取更大的一个 token : )

Seis. Conclusão

与此前出现的可编程任意计算的智能合约系统（如以太坊）相比，Nervos Network 采取了不同的结构；因此，对以往那些智能合约系统的了解，往往难以成为理解 Nervos Network 的基础。本文从一种比 CKB Cell 更为受限的结构 —— BTC UTXO —— 的应用编程出发，提出了一种理解 CKB Cell 可编程性的方法。并且，运用 “内省” 的概念来理解 Cell 的 “跨合约访问” 的能力，我们可以划分运用内省能力的情形，并为它们确定具体的用途。

修订： -> Revisado:

1. Sem considerar a capacidade de acesso cruzado das células (ou seja, a capacidade intrínseca), o lock s pode ser considerado como uma versão extremamente avançada e com capacidade de programação do Bitcoin, portanto, apenas com base nisso, é possível programar todas as aplicações baseadas no Bitcoin;

2. Sem considerar a capacidade de acesso cruzado da célula (ou seja, capacidade de introspecção), a distinção entre lock s e type s pode ser considerada como uma atualização de segurança: ela separa a definição de ativos UDT dos métodos de custódia; além disso, a exposição do estado de type s (bem como Data) realiza o efeito de UDT ser um cidadão de primeira classe.

Acima de tudo, esses dois pontos significam algo com o mesmo paradigma de "BTC + RGB", mas com maior capacidade de programação;

3. Considerando a capacidade de introspecção do Cell, ele pode obter habilidades de programação mais avançadas do que as UTXOs BTC pós-convênios e realizar coisas que são difíceis de serem alcançadas com BTC + RGB (porque o BTC não pode ler o estado do RGB).

Sobre esses usos, este artigo não pode apresentar muitos exemplos específicos, mas isso se deve à falta de compreensão do ecossistema CKB por parte do autor. Com o tempo, acredita-se que as pessoas investirão cada vez mais imaginação nele e criarão aplicações que hoje são difíceis de imaginar.

Agradecimentos

Agradeço ao Retric, Jan Xie e Xue Jie pelo feedback fornecido durante o processo de escrita do artigo. É claro que sou responsável por todos os erros no texto.

"Referências: "

5.\_07\_05\_introdu\u00e7\u00e3o\_ao\_modelo\_de\_valida\u00e7\u00e3o\_de\_programa\_ckb/

6. (II) Contrato de log cauteloso (DLC)

13.\_QUESTION/discussions/7