Instalação
Colocar os arquivos em uma máquina e saber o que você obteve. Rodar um nó de verdade é Rodando um nó; esta página é sobre a instalação.
O Zycord são dois programas de linha de comando e uma aplicação desktop:
| Nome | O que é |
|---|---|
zcd | A ferramenta de linha de comando: chaves, carteiras, gênese, os vetores de referência, e o zcd ui. |
zycordd | O nó: valida, minera, atende pares, responde a uma RPC somente leitura. |
| Zycord Wallet | Uma janela desktop em torno da mesma interface de carteira que o zcd ui serve. |
A primeira release com tag ainda não foi publicada, então construir a partir do código-fonte é atualmente o caminho de entrada, e a seção abaixo é a que se deve ler. As rotas por gerenciador de pacotes e os arquivos de release descritos mais adiante são a forma na qual o projeto será publicado assim que a marcação de tags começar; eles são documentados aqui porque os manifestos estão no repositório e podem ser revisados agora, não porque já haja algo a baixar. A página de releases é onde eles vão aparecer.
Construir a partir do código-fonte#
A versão do Go é go1.26.2, e ela faz parte do código-fonte. Duas releases
do Go compilam o mesmo pacote em código de máquina diferente, então um binário é tanto a saída de um
compilador quanto de um repositório — uma reconstrução com um Go diferente é um arquivo diferente a partir de
uma árvore idêntica. O make build portanto a fixa (GOTOOLCHAIN=go1.26.2 no
Makefile) e se recusa a construir sob qualquer outra, em vez de
lhe entregar um binário cujo hash não vai coincidir sem nenhuma razão aparente.
git clone https://gitlab.com/zycord-group/zycord-node.git
cd zycord-node
make build
Se você não tem o go1.26.2 não precisa ir procurá-lo: a fixação faz o
comando go buscar exatamente esse toolchain no primeiro uso e conferi-lo contra o próprio
banco de checksums do Go. Essa é a única coisa nesta build que toca a rede.
Qual binário pode entrar numa rede#
Este é o parágrafo mais importante da página. O RandomX é compilado atrás de uma build tag, então existem duas builds e apenas uma delas consegue falar com uma rede RandomX — que é tanto a mainnet quanto a testnet pública.
# Default: no cgo, no C toolchain, development engine only.
# Byte-for-byte reproducible. Runs a local devnet and nothing else.
make build # -> bin/zcd, bin/zycordd
# The network binary. cgo, so not reproducible.
make build-randomx # -> bin/zcd-randomx, bin/zycordd-randomx
As duas builds escrevem arquivos diferentes de propósito. Elas costumavam escrever os mesmos
dois caminhos, então a que rodasse por segundo substituía a outra e o nome não dizia nada sobre qual
motor estava dentro dela. Rode zcd-randomx onde a rede for RandomX e zcd
onde não for; ambos estão presentes depois de construir os dois.
Um binário construído sem a tag se recusa a iniciar em uma rede cujo
pow_engine ele não consegue computar. Essa recusa é o ponto: sem outro motor a que recorrer
senão o de desenvolvimento, um nó desses aceitaria uma única passagem BLAKE3 como proof of work para
todo cabeçalho que já visse — toda falsificação válida, todo fork sem peso, e nada registrado.
O inverso não é simétrico: o binário com a tag carrega ambos os motores e roda uma devnet corretamente.
Pergunte a um binário qual deles você tem em mãos:
zcd version
go install para este projetoE isso não é um descuido. O go install resolve um caminho de módulo através do proxy de
módulos, e o módulo raiz se chama zycord — sem host, sem ponto no primeiro elemento
do caminho, o que o toolchain rejeita de saída. O nome é deliberado: o go.mod não reivindica
host algum, porque um host é uma superfície de identidade. O clone acima é a rota do toolchain Go, e ela
é a mais forte de qualquer maneira — você constrói a tag que você mesmo obteve em vez do que quer que um proxy
tenha servido.
Duas camadas de garantia, declaradas em vez de subentendidas#
Assim que houver releases haverá dois conjuntos de arquivos, e eles são conjuntos disjuntos. Esta é a tabela a ler antes de decidir qual pegar.
| Artefato | Reproduzível? | Entra na mainnet? | Por quê |
|---|---|---|---|
zcd, zycordd — compilados do código com make build | Sim, idêntico byte a byte | Não | Go puro, CGO_ENABLED=0, -trimpath, sem build id — e portanto sem engine RandomX. Não é mais distribuído como download; o SHA256SUMS.binaries é publicado para que você possa compilá-lo e comparar. |
zcd, zycordd — arquivo -randomx | Não | Sim | cgo: o RandomX é C++, então um toolchain C do sistema acaba na saída |
| Zycord Wallet, Linux e macOS | Não | n/d | cgo: um toolchain C do sistema e um SDK de plataforma acabam na saída |
| Zycord Wallet, Windows | Sim, idêntico byte a byte | n/d | Sem cgo: o Wails alcança o WebView2 por Go puro |
As releases publicam apenas os arquivos -randomx — uma release que
entrega um arquivo que não consegue entrar numa rede é uma release que entrega uma armadilha. Eles têm
checksum no SHA256SUMS.randomx e deliberadamente não estão no
SHA256SUMS.binaries, porque uma build com cgo é uma que ninguém consegue reconstruir byte a byte.
O SHA256SUMS.binaries lista o hash que uma build feita por você mesmo deve produzir. O motivo de declarar isso é que se trata de uma decisão sua em vez
de uma suposição feita por você.
Por que seu sistema operacional vai avisar você, e por que não há certificado#
Um executável não assinado é bloqueado pelo SmartScreen no Windows e pelo Gatekeeper no macOS. A solução usual é um certificado de assinatura de código. Essa solução é indisponível aqui por construção, não por orçamento, e a razão vale ser compreendida antes de você instalar qualquer coisa — um usuário que sabe por que o aviso aparece é muito mais difícil de enganar com um instalador falso.
Um certificado Authenticode é uma autoridade certificadora atestando uma identidade legal verificada. Essa é sua função inteira; não existe versão dele sem um nome legal dentro. O Apple Developer ID é o mesmo problema com outro fornecedor. O Zycord é publicado pseudonimamente, e comprar um certificado desfaria isso imediatamente.
Então o pseudônimo é mantido. Isso não é um buraco na história de confiança; isso seleciona outra, e para este projeto uma mais forte:
Um certificado afirma "isto veio da entidade X."
Uma build reproduzível afirma "isto veio deste código-fonte, e qualquer um pode conferir."
Para uma rede anônima o segundo é o argumento que se sustenta, e não é um slogan: a CI
reconstrói o zcd duas vezes a cada push para main e a cada tag, e falha se os
dois binários diferirem em um byte. Você não precisa confiar em quem construiu o binário que você baixou.
Você pode construí-lo você mesmo e comparar hashes — e se eles coincidirem, a questão de quem o construiu
deixa de importar. Esse procedimento é Verificando um download.
Gerenciadores de pacotes#
Em vez de brigar com o SmartScreen e o Gatekeeper, o projeto passa pela porta que eles deixam aberta. Um gerenciador de pacotes instala a partir de uma URL e um hash, não exige assinatura, e não dispara nenhum dos avisos. Os manifestos estão no repositório (packaging/) e podem ser revisados agora; os taps que os servem são publicados com a primeira release.
Windows — Scoop#
O Scoop não remove a marca da web; a marca simplesmente nunca é anexada. A
mark-of-the-web é aplicada por navegadores e pela API de shell de execução de anexos do Windows,
não por clientes HTTP puros, e o Scoop baixa através de [Net.HttpWebRequest] ou
aria2. A verificação de reputação de aplicação do SmartScreen dispara em arquivos marcados abertos pelo Explorer; um
arquivo que nunca foi marcado, aberto através de um shim a partir de um terminal, não chega a esse caminho de
forma alguma. O manifesto fixa a URL da release e o SHA-256, então o Scoop verifica o download antes de
instalá-lo.
O que o Scoop instala roda --devnet e recusa a mainnet e a testnet
pública — veja a tabela das duas camadas acima. Para entrar numa rede no Windows, pegue o
zip -randomx para x86-64 na página de downloads; o Windows em
ARM não tem essa build e é apenas devnet. O zcd version imprime qual motor o binário
carrega.
Windows sem Scoop
Um zip portátil é deliberado: não há instalador .exe nem
MSI, porque um instalador não assinado é precisamente o que dispara o pior caminho do SmartScreen —
o bloqueio em tela cheia "O Windows protegeu o seu PC". Arquivos extraídos rodam a partir de um terminal sem
ele. A carteira desktop precisa do runtime WebView2, pré-instalado no Windows 11 e no
Windows 10 atual; se ele estiver faltando a janela não vai abrir e o zcd ui em um navegador
é a maneira de contornar isso.
macOS — Homebrew#
Ambos os pacotes são formulae, não casks, e esse é todo o truque: uma formula constrói a partir do código-fonte na sua máquina, então o binário não é um arquivo baixado e não tem atributo de quarentena. O Gatekeeper nunca o vê. Isso também significa que você não está confiando na build do projeto de forma alguma — o Homebrew busca o tarball do código-fonte, confere seu SHA-256, e o compila com o seu próprio toolchain.
A formula constrói os binários em Go puro, então o que ela instala roda --devnet
e recusa a mainnet e a testnet pública. Para entrar numa rede no macOS, pegue o
arquivo -randomx para a sua arquitetura, ou construa você mesmo com
make build-randomx.
Um cask é o oposto e este projeto não publica um: um .app baixado e
em quarentena, sem assinatura, que só funciona pedindo às pessoas que desativem um
recurso de segurança. O Homebrew está fechando esse caminho deliberadamente —
o --no-quarantine está descontinuado no Homebrew 5.x.
macOS a partir de um zip de release
O .app lá dentro está em quarentena e o macOS vai se recusar a abri-lo.
Para abri-lo assim mesmo: dê um duplo clique nele e dispense a recusa; vá em Ajustes do Sistema →
Privacidade e Segurança, role até Segurança; ao lado de "Zycord Wallet foi
bloqueado", clique em Abrir Assim Mesmo; confirme e autentique.
O macOS 15 (Sequoia) removeu esse atalho. O clique com Control não sobrepõe mais o Gatekeeper, e os Ajustes do Sistema são agora a única rota.
O tarball de linha de comando não tem esse problema: zcd e zycordd são rodados
a partir de um terminal, onde o xattr -d com.apple.quarantine limpa a verificação de primeira execução em
um comando.
Linux#
Nenhum gatekeeper de espécie alguma. Verifique o checksum e a assinatura primeiro — veja Verificando um download — e então:
tar xzf zycord-<version>-linux-amd64-randomx.tar.gz
sudo install -m755 zycord-<version>-linux-amd64-randomx/zcd /usr/local/bin/
sudo install -m755 zycord-<version>-linux-amd64-randomx/zycordd /usr/local/bin/
zcd version # must name randomx-v1
Esse é o único arquivo de nó que uma release publica; não há mais um simples para pegar por
engano. No Debian e no Ubuntu o .deb faz mais do que mover arquivos — ele traz uma
unit do systemd e uma conta sem privilégios — e ambas as rotas, com o script de instalação, estão
dispostas na página de downloads. A carteira
desktop no Linux é publicada como um AppImage, porque o libwebkit2gtk tem um
nome de pacote diferente em cada distribuição.
Em um servidor#
curl | shCanalizar um script não verificado para um shell é a postura errada para software que guarda dinheiro, e é a postura errada mesmo quando o script é deste projeto — todo o argumento desta página é que você não deveria ter que confiar no publicador. O packaging/install.sh baixa, verifica o checksum e a assinatura, e só então instala. Baixe-o, leia-o, e então execute-o.
O install.sh instala o arquivo atestado — o em Go puro
— porque é dessa camada que trata sua verificação de checksum e assinatura, e um script que
verificasse uma assinatura e então instalasse outra coisa seria teatro. Então os binários que ele coloca
em /usr/local/bin recusam a mainnet e a testnet pública, e o script diz isso como
a última coisa que imprime. Para um servidor destinado a entrar numa rede, descompacte o arquivo
-randomx à mão.
Para usar a interface da carteira em um servidor, não exponha uma porta. O zcd
ui vincula ao loopback e recusa qualquer outra coisa; encaminhe-o por ssh. O procedimento está em
Rodando um nó.
Do que nada disto protege você#
Declarado sem rodeios, porque uma página de segurança que só lista suas virtudes é um anúncio.
- Um repositório malicioso. Builds reproduzíveis provam que um binário corresponde ao seu código-fonte. Elas não dizem nada sobre se o código-fonte é honesto. Leia-o — e rode os vetores de referência contra o binário em que você está prestes a confiar.
- Uma página de release falsa. Se alguém montar um clone convincente e você nunca verificar uma assinatura, hashes que coincidam com o arquivo de checksum daquela própria página não provam nada. A impressão digital da chave do projeto
E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29é a âncora. - Uma máquina comprometida. Uma carteira não pode defender um host que já está perdido.
- Um nó mentiroso. O
zcde a carteira não são nós completos; eles acreditam no que um nó lhes diz. É por isso que a carteira recusa um nó cujo chain id divirja da rede que você afirmou, e por que o--confirm-rpcexiste — veja Carteira. - Qualquer um que lhe venda ZCD. Ainda não existe moeda na mainnet. A gênese ainda não aconteceu.