Zycord문서설치

설치

파일을 컴퓨터에 올리고 무엇을 받았는지 아는 방법입니다. 실제로 노드를 운영하는 것은 노드 운영이며, 이 페이지는 설치에 관한 것입니다.

Zycord는 두 개의 명령줄 프로그램과 하나의 데스크톱 애플리케이션입니다.

이름	무엇인가
`zcd`	명령줄 도구입니다. 키, 지갑, 제네시스 블록, 골든 벡터, 그리고 `zcd ui`를 다룹니다.
`zycordd`	노드입니다. 검증하고, 채굴하며, 피어에게 서비스하고, 읽기 전용 RPC에 답합니다.
Zycord Wallet	`zcd ui`가 제공하는 것과 같은 지갑 인터페이스를 감싼 데스크톱 창입니다.

프로젝트의 현재 상태

첫 태그 릴리스가 아직 공개되지 않았으므로 현재로서는 소스에서 빌드하는 것이 진입 방법이며, 아래 절이 읽어야 할 부분입니다. 더 아래에 설명된 패키지 관리자 경로와 릴리스 아카이브는 태깅이 시작되면 이 프로젝트가 배포될 형태입니다. 지금 여기에 문서로 적어 둔 것은 아직 내려받을 것이 있어서가 아니라, 매니페스트가 저장소에 있고 지금 검토할 수 있기 때문입니다. 그것들이 나타날 곳은 릴리스 페이지입니다.

소스에서 빌드하기#

Go 버전은 go1.26.2이며, 이는 소스의 일부입니다. 서로 다른 두 Go 릴리스는 같은 패키지를 서로 다른 기계어로 컴파일하므로, 바이너리는 저장소의 산물인 만큼이나 컴파일러의 산물이기도 합니다 — 다른 Go로 다시 빌드하면 동일한 트리에서 다른 파일이 나옵니다. 그래서 make build는 이 버전을 고정하며(Makefile 안의 GOTOOLCHAIN=go1.26.2), 해시가 맞지 않을 바이너리를 이유도 알려 주지 않고 건네주는 대신 그 밖의 어떤 버전에서도 빌드를 거부합니다.

git clone https://gitlab.com/zycord-group/zycord-node.git
cd zycord-node
make build

go1.26.2가 없어도 직접 찾아 나설 필요는 없습니다. 이 고정 설정 덕분에 go 명령이 처음 쓸 때 바로 그 툴체인을 가져오고 Go 자신의 체크섬 데이터베이스에 대조해 확인합니다. 이 빌드에서 네트워크에 손을 대는 것은 그것뿐입니다.

어떤 바이너리가 네트워크에 참여할 수 있는가#

이 페이지에서 가장 중요한 문단입니다. RandomX는 빌드 태그 뒤에서 컴파일되므로 빌드가 두 종류 있고, 그중 하나만이 RandomX 네트워크와 대화할 수 있습니다 — mainnet과 공개 testnet이 모두 그런 네트워크입니다.

# 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

두 빌드는 의도적으로 서로 다른 파일을 씁니다. 예전에는 둘이 같은 두 경로에 썼기 때문에, 나중에 실행된 쪽이 앞의 것을 덮어썼고 이름만 봐서는 안에 어떤 엔진이 들어 있는지 알 수 없었습니다. 네트워크가 RandomX인 곳에서는 zcd-randomx를, 그렇지 않은 곳에서는 zcd를 실행하세요. 둘 다 빌드하면 둘 다 남아 있습니다.

태그 없이 빌드된 바이너리는 자신이 pow_engine을 계산할 수 없는 네트워크에서 시작을 거부합니다. 그 거부가 핵심입니다. 되돌아갈 엔진이 개발용밖에 없는 상태라면, 그런 노드는 지금까지 본 모든 헤더에 대해 BLAKE3 한 번의 통과를 작업증명으로 받아들일 것입니다 — 모든 위조가 유효한 것이 되고, 모든 포크가 무게를 잃으며, 아무것도 로그에 남지 않습니다. 반대 방향은 대칭이 아닙니다. 태그가 붙은 바이너리는 두 엔진을 모두 담고 있어 devnet도 올바르게 실행합니다.

바이너리에게 지금 손에 든 것이 어느 쪽인지 물어보세요.

zcd version

이 프로젝트에는 go install이 없습니다

그리고 이는 실수가 아닙니다. go install은 모듈 프록시를 통해 모듈 경로를 해석하는데, 루트 모듈의 이름은 zycord입니다 — 호스트도 없고 첫 경로 요소에 점도 없어서 툴체인이 즉시 거부합니다. 이 이름은 의도된 것입니다. go.mod는 어떤 호스트도 주장하지 않는데, 호스트는 신원이 드러나는 표면이기 때문입니다. 위의 클론이 Go 툴체인을 쓰는 경로이며, 어차피 그쪽이 더 강한 경로입니다 — 프록시가 건네준 무언가가 아니라 여러분이 체크아웃한 태그를 빌드하기 때문입니다.

암시하지 않고 명시하는 두 단계의 보증#

릴리스가 생기고 나면 아카이브 묶음이 두 벌이 될 것이며, 그 둘은 서로 겹치지 않는 묶음입니다. 어느 쪽을 가져갈지 정하기 전에 읽어야 할 표가 이것입니다.

산출물	재현 가능한가?	mainnet에 참여하는가?	이유
`zcd`, `zycordd` — `make build`로 소스에서 빌드	예, 바이트 단위로 동일	아니요	순수 Go, `CGO_ENABLED=0`, `-trimpath`, 빌드 id 없음 — 따라서 RandomX 엔진도 없습니다. 더 이상 다운로드로 배포되지 않으며, 직접 빌드해 비교할 수 있도록 `SHA256SUMS.binaries`가 공개됩니다.
`zcd`, `zycordd` — `-randomx` 아카이브	아니요	예	cgo: RandomX는 C++이므로 시스템 C 툴체인이 결과물에 들어갑니다
Zycord Wallet, Linux 및 macOS	아니요	해당 없음	cgo: 시스템 C 툴체인과 플랫폼 SDK가 결과물에 들어갑니다
Zycord Wallet, Windows용	예, 바이트 단위로 동일	해당 없음	cgo 없음: Wails가 순수 Go를 통해 WebView2에 접근합니다

릴리스는 -randomx 아카이브만 배포합니다 — 네트워크에 참여할 수 없는 아카이브를 나눠 주는 릴리스는 발등을 찍을 도구를 나눠 주는 릴리스이기 때문입니다. 이 아카이브들은 SHA256SUMS.randomx로 체크섬이 매겨지며, 의도적으로 SHA256SUMS.binaries에는 들어 있지 않습니다. cgo 빌드는 아무도 바이트 단위로 다시 만들 수 없는 빌드이기 때문입니다. SHA256SUMS.binaries는 여러분이 직접 만든 빌드가 어떤 해시가 되어야 하는지를 나열합니다. 이를 명시하는 이유는 그것이 여러분을 대신해 내려진 가정이 아니라 여러분의 결정이기 때문입니다.

운영체제가 왜 경고하는지, 그리고 왜 인증서가 없는지#

서명되지 않은 실행 파일은 Windows에서는 SmartScreen이, macOS에서는 Gatekeeper가 차단합니다. 통상적인 해결책은 코드 서명 인증서입니다. 여기서 그 해결책은 예산 때문이 아니라 구조상 쓸 수 없으며, 그 이유는 무엇이든 설치하기 전에 이해해 둘 가치가 있습니다 — 경고가 왜 뜨는지 아는 사용자는 가짜 설치 프로그램으로 낚기가 훨씬 어렵습니다.

Authenticode 인증서는 인증 기관이 검증된 법적 신원을 보증하는 것입니다. 그것이 그 인증서의 기능 전부이며, 법적 실명이 들어가지 않는 형태는 존재하지 않습니다. Apple Developer ID도 공급자만 다를 뿐 같은 문제입니다. Zycord는 가명으로 공개되며, 인증서를 사는 순간 그것이 무너집니다.

그래서 가명을 지킵니다. 이는 신뢰에 관한 설명의 구멍이 아니라 다른 설명을 고르는 것이고, 이 프로젝트에는 더 강한 설명입니다.

인증서는 "이것은 X라는 주체에게서 왔다"고 단언합니다.
재현 가능한 빌드는 "이것은 이 소스에서 왔고, 누구나 확인할 수 있다"고 단언합니다.

익명 네트워크에서는 두 번째가 힘을 갖는 논증이며, 이는 구호가 아닙니다. CI는 main으로의 모든 푸시와 모든 태그마다 zcd를 두 번 다시 빌드하고, 두 바이너리가 한 바이트라도 다르면 실패합니다. 여러분이 내려받은 바이너리를 누가 빌드했든 그를 신뢰할 필요가 없습니다. 직접 빌드해 해시를 비교할 수 있고 — 일치한다면 누가 빌드했는가 하는 질문은 더 이상 중요하지 않게 됩니다. 그 절차가 다운로드 검증입니다.

패키지 관리자#

SmartScreen 및 Gatekeeper와 싸우는 대신, 이 프로젝트는 그들이 열어 둔 문으로 들어갑니다. 패키지 관리자는 URL과 해시로부터 설치하고, 서명을 요구하지 않으며, 어느 쪽 경고도 건드리지 않습니다. 매니페스트는 저장소에 (packaging/) 있고 지금 검토할 수 있습니다. 그것들을 제공하는 탭은 첫 릴리스와 함께 공개됩니다.

Windows — Scoop 사용#

Scoop이 웹 표식을 벗겨 내는 것이 아닙니다. 애초에 표식이 붙지 않습니다. 웹 표식은 브라우저와 Windows의 첨부 파일 실행 셸 API가 붙이는 것이지 순수 HTTP 클라이언트가 붙이는 것이 아니며, Scoop은 [Net.HttpWebRequest]나 aria2를 통해 내려받습니다. SmartScreen의 애플리케이션 평판 검사는 탐색기에서 실행된 표식 붙은 파일에 대해 발동합니다. 한 번도 표식이 붙은 적 없고 터미널에서 심을 통해 실행되는 파일은 그 경로에 아예 이르지 않습니다. 매니페스트는 릴리스 URL과 SHA-256을 고정하므로, Scoop은 설치하기 전에 다운로드를 검증합니다.

Scoop이 설치하는 것은 --devnet에서 실행되며 mainnet과 공개 testnet은 거부합니다 — 위의 두 계층 표를 보세요. Windows에서 네트워크에 참여하려면 다운로드 페이지에서 x86-64용 -randomx zip을 가져가세요. Windows on ARM에는 그런 빌드가 없어 devnet 전용입니다. zcd version은 그 바이너리가 어떤 엔진을 담고 있는지 출력합니다.

Scoop 없이 Windows에서

이동식 zip은 의도된 것입니다. .exe 설치 프로그램도 MSI도 없는데, 서명되지 않은 설치 프로그램이야말로 최악의 SmartScreen 경로를 유발하는 바로 그것이기 때문입니다 — 전체 화면을 덮는 "Windows가 PC를 보호했습니다" 차단 말입니다. 압축을 푼 파일들은 터미널에서 그런 차단 없이 실행됩니다. 데스크톱 지갑에는 WebView2 런타임이 필요하며, Windows 11과 최신 Windows 10에는 미리 설치되어 있습니다. 없으면 창이 열리지 않으며, 브라우저에서 zcd ui를 쓰는 것이 우회로입니다.

macOS — Homebrew 사용#

두 패키지는 캐스크가 아니라 포뮬러이며, 그것이 요령의 전부입니다. 포뮬러는 여러분 컴퓨터에서 소스로부터 빌드하므로, 그 바이너리는 내려받은 파일이 아니고 격리 속성도 없습니다. Gatekeeper는 그것을 아예 보지 못합니다. 또한 이는 여러분이 프로젝트의 빌드를 전혀 신뢰하지 않아도 된다는 뜻이기도 합니다 — Homebrew가 소스 타르볼을 가져와 SHA-256을 확인하고, 여러분 자신의 툴체인으로 컴파일합니다.

이 포뮬러는 순수 Go 바이너리를 빌드하므로, 그것이 설치하는 것은 --devnet에서 실행되며 mainnet과 공개 testnet은 거부합니다. macOS에서 네트워크에 참여하려면 여러분의 아키텍처에 맞는 -randomx 아카이브를 가져가거나, make build-randomx로 직접 빌드하세요.

캐스크는 그 반대이며 이 프로젝트는 캐스크를 배포하지 않습니다. 캐스크는 서명이 없고 격리된 채 내려받아진 .app이며, 사람들에게 보안 기능을 끄라고 요구해야만 동작합니다. Homebrew도 그 경로를 의도적으로 닫고 있습니다 — Homebrew 5.x에서 --no-quarantine은 폐기 예정입니다.

릴리스 zip으로 macOS에서

그 안의 .app은 격리되어 있으며 macOS는 열기를 거부합니다. 그래도 열려면, 더블클릭한 뒤 거부 메시지를 닫고, 시스템 설정 → 개인정보 보호 & 보안으로 가서 보안까지 스크롤한 다음, "Zycord Wallet이 차단되었습니다" 옆의 그래도 열기를 클릭하고, 확인한 뒤 인증하세요.

Control-클릭 후 열기를 고르라는 옛 조언은 따르지 마세요

macOS 15 (Sequoia)에서 그 방법이 제거되었습니다. Control-클릭은 더 이상 Gatekeeper를 무시하지 않으며, 이제 시스템 설정이 유일한 경로입니다.

명령줄 타르볼에는 그런 문제가 없습니다. zcd와 zycordd는 터미널에서 실행되며, 거기서는 xattr -d com.apple.quarantine 한 번으로 최초 실행 검사가 해제됩니다.

Linux#

어떤 종류의 게이트키퍼도 없습니다. 먼저 체크섬과 서명을 검증하세요 — 다운로드 검증을 보세요 — 그런 다음

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

릴리스가 배포하는 노드 아카이브는 그것뿐이며, 실수로 고를 수 있는 평범한 아카이브는 더 이상 없습니다. Debian과 Ubuntu에서는 .deb가 파일을 옮기는 것 이상을 합니다 — systemd 유닛과 권한 없는 계정을 함께 가져옵니다 — 그리고 설치 스크립트를 포함한 두 경로 모두가 다운로드 페이지에 정리되어 있습니다. Linux에서 데스크톱 지갑은 AppImage로 배포되는데, libwebkit2gtk의 패키지 이름이 배포판마다 다르기 때문입니다.

서버에서#

결코 curl | sh로 하지 마세요

검증하지 않은 스크립트를 셸에 파이프로 밀어 넣는 것은 돈을 다루는 소프트웨어에 어울리지 않는 자세이며, 그 스크립트가 이 프로젝트의 것일 때조차 어울리지 않는 자세입니다 — 이 페이지의 논증 전체가 여러분이 게시자를 신뢰할 필요가 없어야 한다는 것이기 때문입니다. packaging/install.sh는 내려받은 뒤 체크섬과 서명을 검증하고, 그런 다음에야 설치합니다. 내려받아 읽어 보고, 그런 다음 실행하세요.

install.sh는 증명된 아카이브 — 순수 Go 쪽 — 를 설치합니다. 그 스크립트의 체크섬과 서명 확인 절차가 다루는 것이 바로 그 계층이고, 서명을 검증한 다음 다른 것을 설치하는 스크립트는 연극에 지나지 않을 것이기 때문입니다. 따라서 그것이 /usr/local/bin에 넣는 바이너리들은 mainnet과 공개 testnet을 거부하며, 스크립트도 마지막으로 그렇게 출력합니다. 네트워크에 참여할 서버라면 -randomx 아카이브를 손으로 풀어 쓰세요.

서버에서 지갑 인터페이스를 쓰려면 포트를 노출하지 마세요. zcd ui는 루프백에 바인드하며 그 밖의 어떤 것도 거부합니다. ssh로 포워딩하세요. 절차는 노드 운영에 있습니다.

이 가운데 어느 것도 여러분을 지켜 주지 못하는 것#

자기 장점만 나열하는 보안 페이지는 광고에 지나지 않으므로, 솔직하게 적습니다.

악의적인 저장소. 재현 가능한 빌드는 바이너리가 자기 소스와 일치한다는 것을 증명합니다. 그 소스가 정직한지에 대해서는 아무 말도 하지 않습니다. 직접 읽으세요 — 그리고 이제 신뢰하려는 그 바이너리에 대고 골든 벡터를 돌려 보세요.
가짜 릴리스 페이지. 누군가 그럴듯한 복제본을 세워 두었는데 여러분이 서명을 한 번도 검증하지 않는다면, 그 페이지 자신의 체크섬 파일과 해시가 맞는다는 사실은 아무것도 증명하지 않습니다. 프로젝트 키 지문 E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29이 기준점입니다.
이미 장악된 컴퓨터. 지갑은 이미 잃어버린 호스트를 지켜 낼 수 없습니다.
거짓말하는 노드. zcd와 지갑은 풀 노드가 아니며, 노드가 말해 주는 것을 믿습니다. 그래서 지갑은 여러분이 단언한 네트워크와 체인 id가 어긋나는 노드를 거부하고, 그래서 --confirm-rpc가 존재합니다 — 지갑을 보세요.
여러분에게 ZCD를 팔겠다는 사람 누구든. 아직 mainnet 코인은 없습니다. 제네시스 블록은 아직 생기지 않았습니다.