O Statechains é um protocolo original de segunda camada originalmente desenvolvido por Ruben Somsen em 2018, dependendo da proposta Eltoo (ou LN Symmetry). Em 2021, uma variação da proposta original, Mercury, foi construída pelo CommerceBlock. Em 2024, foi construída uma iteração adicional do esquema de mercúrio original, a camada de mercúrio.
O protocolo Statechain é um pouco mais complicado de discutir em comparação com outros sistemas, como ARK ou Lightning, devido à gama de variações possíveis entre o design proposto original, os dois que foram realmente implementados e outros projetos possíveis que foram rapidamente propostos.
Como o ARK, o Statechains depende de um servidor de coordenação centralizado para funcionar. Ao contrário da ARK, eles têm um modelo de confiança ligeiramente diferente de um vutxo em um lote de arca. Eles dependem do servidor de coordenação para excluir ações geradas anteriormente de uma chave privada para permanecer sem confiança, mas enquanto o servidor siga o protocolo definido e o faz, eles fornecem uma forte garantia de segurança.
A idéia geral de um Statechain é poder transferir a propriedade de um UTXO inteiro entre diferentes usuários fora da cadeia, facilitado pelo coordenador. Não há exigência para receber liquidez como um raio ou o servidor coordenador para fornecer qualquer liquidez como a ARK.
Para começar, examinaremos o protocolo original proposto por Ruben Somsen.
O Statechain original
O Statechains é efetivamente uma transação pré-assinada, permitindo que o atual proprietário do Statechain retire unilateralmente na cadeia sempre que quiserem, e uma história assinou mensagens criptograficamente comprovando que os proprietários e os receptores enviaram o Statechain para aprovaram essas transferências.
O design original foi construído no ELTOO usando AnyPrevout, mas os planos atuais de como permitir a mesma funcionalidade utilizam o CheckTemPlatimsify e o CheckSigfromStack (uma explicação de alto nível está no final do artigo Checksigfromstack). A idéia básica é um script que permite uma transação pré-assinada gastar qualquer UTXO que tenha esse script e bloqueia a quantidade apropriada de bitcoin, em vez de estar ligado a gastar um único UTXO específico.
No protocolo, um usuário que deseja depositar suas moedas em um Statechain se aproxima de um servidor coordenador e passa por um protocolo de depósito. O usuário depositando, Bob, gera uma chave que pertence exclusivamente a ele, mas também uma segunda chave “transitória” que será compartilhada (mais sobre isso em breve). Eles então criam uma transação de depósito bloqueando sua moeda a um multisig que exige a chave do coordenador e a chave transitória para assinar.
Usando esse multisig, Bob e o coordenador assinam uma transação que gasta que cunha e cria um UTXO que pode ser gasto por qualquer outra transação assinada pela chave transitória e pela chave do coordenador usando simetria LN ou a chave única de Bob após uma timelock. Bob agora pode financiar o multisig com a quantidade apropriada e o Statechain foi criado.
Para transferir um Statechain para Charlie, Bob deve passar por um processo de várias etapas. Primeiro, Bob assina uma mensagem com sua chave privada única que atesta o fato de que ele vai transferir o Statechain para Charlie. Charlie também deve assinar uma mensagem atestando o fato de ter recebido o Statechain de Bob. Finalmente, o servidor coordenador deve assinar uma nova transação, permitindo que Charlie reivindique unilateralmente o Statechain na cadeia antes de Bob enviar Charlie uma cópia da chave transitória.
Tudo isso é feito atômico usando assinaturas adaptadoras. Essas são assinaturas que são modificadas de tal maneira usando uma peça aleatória de dados que os torna inválidos, mas podem ser válidos novamente quando o titular da assinatura receber essa informação. Todas as mensagens e a nova transação pré-assinada são assinadas com assinaturas adaptadoras e tornadas atomicamente válidas ao mesmo tempo através da liberação dos dados do adaptador.
Os titulares de um Statechain devem confiar que o servidor coordenador nunca conspira com um proprietário anterior para assinar um fechamento imediato dos fundos Statechain e roubar do proprietário atual, mas a cadeia de mensagens pré-assinadas pode provar que um coordenador participou de roubo se o fizer. Se um proprietário anterior tentar usar sua transação pré-assinada para roubar os fundos, o cronograma no caminho de gasto usando apenas sua chave permite que o proprietário atual envie sua transação pré-assinada e reivindique corretamente os fundos na cadeia.
Camada de Mercúrio e Mercúrio
A arquitetura Statechain original requer um softfork para funcionar. O CommerceBlock projetou sua variante de Statechains para funcionar sem um softfork, mas para fazê -lo, foram feitas compensações em termos de funcionalidade.
A idéia básica é a mesma que o design original, todos os usuários mantêm uma transação pré-assinada que lhes permite reivindicar seus fundos unilateralmente, e o servidor coordenador ainda desempenha uma função na facilitação de transferências fora da cadeia que exige que eles sejam confiáveis para se comportarem honestamente. As duas principais diferenças são como essas transações são assinadas e a estrutura dos usuários de transações pré-assinadas são fornecidas.
No que diz respeito à assinatura, não há mais uma chave privada transitória passada de usuário para usuário. Em vez disso, é usado um protocolo multipartidário de computação (MPC) para que o proprietário original e o servidor do coordenador possam gerar colaborativamente peças parciais de uma chave privada sem que nenhum deles possua a chave completa. Esta chave é usada para assinar as transações pré-assinadas. O protocolo MPC permite que o atual proprietário e o coordenador se envolvam em um segundo protocolo com terceiros, o destinatário de uma transferência, para regenerar peças diferentes que somam a mesma chave privada. No protocolo de Mercury e Mercury Cayer, depois de concluir uma transferência, um servidor coordenador honesto exclui o material principal correspondente ao proprietário anterior. Enquanto isso estiver feito, não é mais possível para o coordenador assinar uma transação com um proprietário anterior, pois a nova peça de material chave que eles possuem não é compatível com a peça que qualquer proprietário anterior ainda pode ter. Esta é realmente uma garantia mais forte, desde que o coordenador seja honesto, que a proposta original.
A estrutura de transação pré-assinada para a camada de mercúrio e mercúrio não pode usar a simetria de LN, pois isso não é possível sem um softfork. Em vez disso, o CommerceBlock optou por usar cronogramas decrescentes. A transação pré-assinada do proprietário original é estilizada usando o NLOCKTIME para um tempo distante no futuro a partir do ponto da criação do Statechain. Como cada usuário subsequente recebe o Statechain durante uma transferência, o valor nlocktime de sua transação é um período de tempo pré-determinado mais curto que o proprietário anterior. Isso garante que um proprietário anterior seja incapaz de tentar enviar sua transação na cadeia antes que o proprietário atual possa, mas também significa que, eventualmente, em algum momento o proprietário atual deve fechar seu Statechain na cadeia antes que as transações dos proprietários anteriores comecem a se tornar válidos.
A principal diferença entre Mercúrio e Camada de Mercúrio é como essas transações são assinadas. No caso de Mercúrio, o servidor coordenador simplesmente vê a transação proposta, verifica -a e o assina. A Camada de Mercúrio usa um protocolo de assinatura cega, o que significa que eles realmente não vêem detalhes da transação que estão assinando. Isso requer o servidor Rastreando Statechains usando registros anonimizados no servidor e uma chave de autorização especial do proprietário atual, para que eles possam ter certeza de que estão assinando apenas transferências válidas.
Sinergia com outras camadas
O Statechains pode sinergizar com outras camadas 2s baseadas em transações pré-assinadas. Por exemplo, parte da proposta original sugeriu uma combinação de Statechains e Lightning Channels. Como ambos são simplesmente transações pré-assinadas, é possível aninhar um canal de raios em cima de um Statechain. Isso simplesmente exige que a chave de saída unilateral do proprietário atual seja um multisig e a criação das transações pré-assinadas gastando essa saída em um canal de raios. Isso permite que os canais de raios sejam abertos e fechados totalmente fora da cadeia.
De maneira semelhante, é possível aninhar um Statechain em cima de um vutxo em um lote de arca. Isso simplesmente requer as transações pré-assinadas necessárias para que um Statechain seja construído, gastando a saída Vutxo.
Embrulhando
Os Statechains não são totalmente confiáveis, mas são um esquema minimizado de confiança que é muito eficiente em liquidez e permite transferir livremente a UTXOS para fora da cadeia entre todos os usuários dispostos a aceitar o modelo de confiança dos Statechains.
Embora a proposta original ainda não tenha sido construída, as duas implementações projetadas pelo CommerceBlock foram completamente implementadas. Ambos não conseguiram alcançar nada além do uso marginal no mundo real. Se isso se deve ao fato de os usuários não estarem dispostos a aceitar o modelo de confiança envolvido ou simplesmente uma falha no marketing ou na conscientização é algo que não pode ser totalmente verificado.
Independentemente disso, dado que há duas implementações e projetos completos para uma variação mais flexível, caso a simetria de LN já se torne possível no Bitcoin, esta uma opção que sempre estará aqui. O bom do software de código aberto é que ele sempre estará lá, independentemente de as pessoas usá -lo agora, devem escolher no futuro.
