#dusk $DUSK @Dusk estive indo e voltando sobre alguma coisa relacionada ao anoitecer/dusk e acho que finalmente encontrei a forma real disso.
procurei a lista de provisionadores faz um tempo — os quinze endereços principais concentram pouco menos da metade de tudo que está vinculado/bonded, nenhum deles tem barras/“slashes”, e o participante mais antigo está em funcionamento há mais de um ano, enquanto o mais novo amadureceu dias atrás. tudo isso fica lá, por endereço, recalculado a cada bloco. isso é rigor de verdade. ninguém precisa confiar numa afirmação sobre quem assegura esta cadeia; eles podem simplesmente olhar.
então aconteceu a questão da ponte. a carteira sinalizou, os fundos foram movidos, o time pausou e enviou um correção — só que a correção não estava naquela mesma camada “comprovável”. era uma blocklist de destinatários que ficava no frontend da carteira web. se você estiver rodando suas próprias ferramentas ou a CLI, você não herda nenhuma dessas proteções. nada disso toca a parte da pilha que de fato fica aberta a inspeção.
então aqui está o que tem me deixado com isso estranho: a parte do dusk que é rigorosamente responsável/prestável (quem detém stake, por quanto tempo, quais penalidades) não é a parte que teve que responder quando algo deu errado de verdade. a parte que respondeu estava em algum lugar que ninguém consegue auditar do mesmo jeito.
não estou dizendo que isso seja necessariamente uma troca ruim — lançar rápido provavelmente importava mais naquela semana do que a pureza arquitetural. mas se uma instituição estiver avaliando o dusk em “quão comprovável é este sistema”, ela pode estar avaliando uma camada diferente daquela que vai realmente pegar o próximo incidente.
então qual camada você realmente gostaria que fosse auditada primeiro — a que detém o stake, ou a que decide quem tem permissão para mover fundos?
procurei a lista de provisionadores faz um tempo — os quinze endereços principais concentram pouco menos da metade de tudo que está vinculado/bonded, nenhum deles tem barras/“slashes”, e o participante mais antigo está em funcionamento há mais de um ano, enquanto o mais novo amadureceu dias atrás. tudo isso fica lá, por endereço, recalculado a cada bloco. isso é rigor de verdade. ninguém precisa confiar numa afirmação sobre quem assegura esta cadeia; eles podem simplesmente olhar.
então aconteceu a questão da ponte. a carteira sinalizou, os fundos foram movidos, o time pausou e enviou um correção — só que a correção não estava naquela mesma camada “comprovável”. era uma blocklist de destinatários que ficava no frontend da carteira web. se você estiver rodando suas próprias ferramentas ou a CLI, você não herda nenhuma dessas proteções. nada disso toca a parte da pilha que de fato fica aberta a inspeção.
então aqui está o que tem me deixado com isso estranho: a parte do dusk que é rigorosamente responsável/prestável (quem detém stake, por quanto tempo, quais penalidades) não é a parte que teve que responder quando algo deu errado de verdade. a parte que respondeu estava em algum lugar que ninguém consegue auditar do mesmo jeito.
não estou dizendo que isso seja necessariamente uma troca ruim — lançar rápido provavelmente importava mais naquela semana do que a pureza arquitetural. mas se uma instituição estiver avaliando o dusk em “quão comprovável é este sistema”, ela pode estar avaliando uma camada diferente daquela que vai realmente pegar o próximo incidente.
então qual camada você realmente gostaria que fosse auditada primeiro — a que detém o stake, ou a que decide quem tem permissão para mover fundos?
