Tự lưu trữ BTCPay Server trên VPS

Lời chào mời thường là “miễn phí giao dịch”, đây lại là phần ít thú vị nhất. Có bốn điều thực sự thay đổi, và chỉ một trong số đó liên quan đến tiền:

• Không ai giữ tiền của bạn trong lúc nó đang chuyển. Một bộ xử lý thanh toán có sẵn nhận khoản thanh toán của khách hàng vào ví riêng của nó rồi mới ghi có cho bạn sau đó. Chính khoảng trống đó là nơi xảy ra việc giữ tiền, xét duyệt và đóng băng. BTCPay không bao giờ nhận bất cứ thứ gì: khách hàng trả tiền vào một địa chỉ được dẫn xuất từ khóa của bạn, và số coin đó là của bạn ngay từ xác nhận đầu tiên.
• Không ai hỏi bạn là ai. Việc đăng ký với một bộ xử lý thanh toán là một quy trình xác minh danh tính có ngân hàng đứng ở cuối. Cài đặt phần mềm thì không. Đó là toàn bộ sự khác biệt, và đó là lý do câu trả lời cho “làm sao để nhận crypto mà không cần KYC” luôn luôn là “tự chạy lấy bộ xử lý thanh toán”.
• Chi phí không còn tăng theo bạn nữa. Một tỷ lệ phần trăm bị thu mãi mãi và lớn dần theo thành công của bạn. Một VPS và một domain thì tốn như nhau dù trong một tháng tốt hay một tháng tệ.
• Bạn thừa hưởng luôn phần việc vận hành. Uptime, cập nhật, sao lưu, và trở thành người nhận tin nhắn khi một khách hàng nói rằng hóa đơn không bao giờ được xác nhận. Đây mới là cái giá thực sự, và nó được trả bằng sự chú tâm chứ không phải bằng tiền.

Thứ bạn không có được chính là điều duy nhất mà các bộ xử lý thanh toán thực sự làm tốt: biến coin thành tiền trong tài khoản ngân hàng thay bạn. BTCPay chỉ giữ đúng thứ nó được trả, bằng đúng đồng coin nó được trả. Quy đổi, xuất hóa đơn bằng tiền pháp định, xuất báo cáo kế toán mà cơ quan thuế công nhận — tất cả đều là những bài toán riêng biệt, và phần lớn cách giải quyết chúng lại đưa trở lại chính xác cái bên thứ ba đã được định danh mà bạn vừa mới loại bỏ. Hãy xác định rõ bạn thực sự muốn nửa nào trong sự đánh đổi đó trước khi xây dựng bất cứ thứ gì.

Cái tên này gây hiểu lầm theo một cách hữu ích. “BTCPay Server” không phải một chương trình duy nhất; bản triển khai chuẩn là một cụm nhỏ các container khởi động cùng nhau, và biết rõ cái nào là cái nào chính là khác biệt giữa việc chọn đúng cấu hình và việc đoán mò:

• Bitcoin Core. Một full node thực thụ, xác thực từ genesis. Đây là thành phần ngốn ổ đĩa, chiếm gần trọn ngày đầu tiên, và ngốn gần hết bộ nhớ. Mọi thứ khác so ra gần như miễn phí.
• NBXplorer. Bộ lập chỉ mục nằm giữa Core và BTCPay. Bạn đưa cho nó các khóa công khai mở rộng; nó theo dõi các địa chỉ dẫn xuất và báo cho BTCPay biết khi tiền về. Đây cũng là thành phần quan tâm đến pruning, vì những lý do phần các kiểu lỗi thường gặp sẽ nhắc lại.
• Bản thân BTCPay Server. Ứng dụng chính: cửa hàng, hóa đơn, trang thanh toán, điểm bán hàng, webhook, Greenfield API. Nhẹ nhàng hơn hẳn so với phần còn lại — chỉ vài trăm megabyte bộ nhớ.
• PostgreSQL. Hóa đơn, cửa hàng, cài đặt, người dùng, API key. Nhỏ gọn, và đây mới thực sự là thứ các bản sao lưu của bạn tồn tại vì nó.
• nginx kèm chứng chỉ tự động. Một reverse proxy cộng với một tiến trình đi kèm chuyên cấp và gia hạn chứng chỉ cho hostname của bạn. Đây là lý do cổng 80 và 443 phải thực sự tiếp cận được từ internet.
• Tùy chọn thêm một node Lightning (Core Lightning hoặc LND) và một daemon Monero cùng một wallet RPC đi kèm — mỗi thứ lại mang theo chuỗi riêng và sự thèm khát ổ đĩa của riêng nó.

Vậy nên câu hỏi về cấu hình không bao giờ là “BTCPay cần lớn cỡ nào”. Mà là “mình đang giữ bao nhiêu chuỗi, và bao nhiêu chuỗi tất cả”. Trả lời được câu đó thì gói phù hợp sẽ tự lộ ra.

Dự án ghi trong tài liệu mức 2 GB RAM cộng swap là tối thiểu và 4 GB là khuyến nghị, và khoảng cách giữa hai con số đó chính là khoảng cách giữa một bản cài đặt về mặt kỹ thuật thì chạy xong và một bản bạn thực sự sẵn lòng trỏ khách hàng vào. Một runtime ứng dụng, PostgreSQL và một bitcoind đang đồng bộ chia nhau 2 GB vẫn sẽ chạy xong — chỉ là chậm, với file swap phải gánh phần việc lẽ ra nó không nên gánh.

Dung lượng ổ đĩa được quyết định bởi việc bạn prune mạnh tay đến mức nào, và bản triển khai này thể hiện điều đó dưới dạng một fragment mà bạn truyền cho trình cài đặt. Nhóm fragment đó chạy quanh mức opt-save-storage ở khoảng 100 GB tệp block, -s ở khoảng 50 GB, -xs ở khoảng 25 GB và -xxs ở khoảng 5 GB. Lựa chọn cuối cùng đó là một cái bẫy cho bất cứ thứ gì cần tồn tại lâu dài: nó giữ lại quá ít lịch sử đến mức việc bảo trì thông thường bắt đầu thất bại. Với một cửa hàng, -s hoặc -xs là dải hợp lý.

Số liệu cụ thể từ bảng giá, vì “còn tùy” không phải là một câu trả lời:

• Chỉ Bitcoin, pruned, một cửa hàng — Scout, 2 vCPU / 4 GB / 70 GB NVMe, $9.00/mo. Mức sàn trung thực, và câu trả lời đúng cho phần lớn độc giả.
• Bitcoin và Lightning — Runner, 3 vCPU / 6 GB / 100 GB, $14.00/mo. Một daemon Lightning nhẹ ổ đĩa nhưng khăng khăng đòi luôn trực tuyến; phần dư ra là dành cho node bên dưới nó.
• Bitcoin, Lightning và Monero — Alpha, 6 vCPU / 12 GB / 200 GB, $28.00/mo. Một chuỗi Monero pruned chỉ riêng nó đã tốn khoảng 85 GB, nên hai chuỗi cộng hai bộ lập chỉ mục là lúc 8 GB bắt đầu hụt hơi. Hunter (4 vCPU / 8 GB / 140 GB, $19.00/mo) chỉ vừa nếu Bitcoin luôn được prune mạnh tay và giữ nguyên như vậy.
• Một node unpruned đứng sau cửa hàng — đó là một dự án khác với một hóa đơn khác. Hướng dẫn full-node có đủ những con số đó, và chúng bắt đầu từ Fenrir.

CPU chỉ quan trọng đúng một lần. Việc xác minh chữ ký trong quá trình tải khối ban đầu (initial block download) chạy song song được, nên 2 đến 4 vCPU biến lần đồng bộ đầu tiên từ vài ngày xuống còn khoảng một ngày, rồi sau đó quay về trạng thái nhàn rỗi. Băng thông là một chi phí một lần cho toàn bộ chuỗi, trên một cổng 1 Gbps với lưu lượng không giới hạn và không có hóa đơn phụ trội vào cuối tháng. Độ trễ không quan trọng với một bộ xử lý thanh toán, nên hãy chọn vị trí theo khu vực pháp lý chứ không phải theo mili-giây — Amsterdam, Paris, Bucharest và Sofia đều có giá cơ bản.

Một danh sách ngắn, và một mục trong đó không hề mang tính kỹ thuật.

• Một domain, với bản ghi A đã trỏ sẵn vào máy chủ. Chứng chỉ được cấp qua HTTP dựa trên đúng hostname đó, nên DNS phải phân giải được trước khi trình cài đặt chạy, không phải trong lúc chạy. Một subdomain kiểu pay.example.com là hình thức thông thường.
• Cổng 80 và 443 mở ra với cả thế giới. Cổng 80 không phải tùy chọn dù sau này chẳng có gì hữu ích phục vụ trên đó; thử thách cấp chứng chỉ cần đến nó.
• Debian 13 từ thư viện template, trên một máy đã trải qua lượt tăng cường bảo mật mười phút. Hãy làm việc đó trước — một khi stack đã chạy thì khó lòng làm cho gọn gàng hơn nhiều.
• Một ví bạn đã kiểm soát sẵn, cùng khóa công khai mở rộng của nó. Sparrow, Electrum hoặc một ví cứng. Có sẵn nó trong tay trước khi cài đặt, để bạn không bao giờ bị cám dỗ để mặc máy chủ tự tạo một cái cho bạn.
• Một địa chỉ email cho certificate authority. Nó chỉ nhận cảnh báo hết hạn và không gì khác.
• Một quyết định về pruning, chốt ngay bây giờ. Đổi ý sau này nghĩa là phải đồng bộ lại chuỗi từ đầu, một ngày mà bạn sẽ không muốn trải qua đến lần thứ hai.

Gần như mọi kết cục tệ với một bộ xử lý thanh toán tự lưu trữ đều bắt nguồn từ một quyết định duy nhất được đưa ra sớm và tùy tiện: để máy chủ giữ thứ gì đó có thể chi tiêu được. Đáng để nói rõ về ba trường hợp, vì chúng thực sự khác nhau.

• Bitcoin on-chain: watch-only, luôn luôn như vậy. BTCPay chỉ giữ một khóa công khai mở rộng và không gì khác. Nếu máy bị xâm nhập, kẻ tấn công biết được bạn đã được trả bao nhiêu và có thể đổi hướng các hóa đơn tương lai trỏ đến — một cuộc tấn công có thật, và là lý do để kiểm tra lại ví của cửa hàng bạn sau bất kỳ sự cố nào — nhưng không thể động vào một đồng coin đã nhận rồi.
• Lightning: hot, đúng theo định nghĩa. Các kênh được cấp vốn bằng coin mà máy chủ có thể chi tiêu, vì bản chất một kênh là như vậy. Đây là ngoại lệ có chủ đích, và phần trên đã tính cấu hình cho nó.
• Monero: view-only, xét về mặt cấu trúc. Khóa xem riêng tư tiết lộ mọi khoản thanh toán đến nhưng không cho phép chi tiêu bất kỳ khoản nào trong số đó. Không có gì tương đương ở phía Bitcoin.

Tính năng duy nhất phá vỡ mô hình này một cách có chủ đích là Payjoin. Nó cho phép máy chủ của bạn đóng góp một input vào giao dịch của khách hàng, làm suy yếu đáng kể phép suy đoán dựa trên đầu vào chung (common-input heuristic) mà các công cụ phân tích chuỗi vẫn dựa vào, đồng thời mang lại lợi ích riêng tư thực sự cho cả hai bên — nhưng bên nhận phải có khả năng ký, nên nó cần một ví hot bên trong BTCPay. Đó là một sự đánh đổi thực sự, không phải một tính năng miễn phí. Hãy dùng nó một cách có ý thức, và cấp vốn cho nó giống cách bạn cấp vốn cho ví Lightning: theo một khoản cụ thể, không phải toàn bộ.

Và nếu bạn để wizard thiết lập tự tạo ví cho cửa hàng vì đó là con đường nhanh nhất: hãy ghi lại seed mà nó cho bạn xem, xác minh nó trong một ví offline, rồi lên kế hoạch chuyển sang thiết lập watch-only. Một seed đã từng xuất hiện trên một máy chủ có kết nối internet là một seed đã bắt đầu đếm ngược.

Hãy sắp xếp trạng thái theo mức độ khó để tái tạo lại, vì câu trả lời cho mỗi thứ rất khác nhau:

• Chuỗi. Không phải vấn đề sao lưu. Đây là dữ liệu công khai và nó tự đồng bộ lại, chậm nhưng miễn phí. Đừng bao giờ sao lưu nó.
• Cơ sở dữ liệu. Hóa đơn, cửa hàng, cài đặt, người dùng, API key. Đây mới là bản sao lưu thực sự, nó nhỏ gọn, và mất nó khiến bạn mất luôn bản ghi kế toán của mọi giao dịch — không phải mất tiền, mà là mất giấy tờ.
• Ví on-chain của bạn. Đã an toàn sẵn rồi, vì khóa chưa bao giờ nằm ở đây. Đó chính là thành quả của bước năm.
• Trạng thái kênh Lightning. Đây mới là thứ gây đau. Một static channel backup cho phép bạn khôi phục số tiền trong các kênh của bạn sau một tổn thất toàn bộ bằng cách buộc đóng chúng lại; nó không khôi phục lại các kênh, và nó vô giá trị nếu đã cũ. Nó thay đổi mỗi khi một kênh mở hoặc đóng, nên nó thuộc về một bản sao tự động lưu ngoài máy chủ, chứ không phải một thư mục mà bạn nhớ tới mỗi quý một lần.
• Ví view-only của Monero. Có thể dựng lại từ địa chỉ và khóa xem mà bạn vẫn giữ offline. Hãy sao lưu hai thứ đó và coi các tệp ví chỉ là một cache.

Bản triển khai đi kèm sẵn các script hỗ trợ làm đúng việc này:

btcpay-backup.sh    # stops the stack, dumps Postgres, tars the config, restarts
btcpay-restore.sh   # puts one of those archives back

Khoảng dừng đó chính là điểm mấu chốt — một bản sao hot của một cơ sở dữ liệu đang chạy có thể khôi phục ra một thứ gì đó thú vị. Hãy mã hóa bất cứ thứ gì rời khỏi máy, và nhớ rằng snapshot hàng tuần đi kèm mọi gói chỉ là một tiện ích chứ không phải một bản sao lưu: một snapshot sống chung với chính thứ nó đang bảo vệ.

Xếp theo thứ tự tương đối về mức độ chúng hay ngốn mất một buổi tối của ai đó:

• Chứng chỉ không bao giờ được cấp. Chín trên mười lần là do bản ghi A được tạo sau khi trình cài đặt đã chạy, hoặc cổng 80 bị lọc chặn. Hãy sửa DNS, xác nhận tên đã phân giải được từ một nơi không phải laptop của chính bạn, rồi chạy lại script cài đặt. Cứ mù quáng thử lại với certificate authority sẽ khiến bạn dính giới hạn tốc độ và mất thêm một tuần chờ đợi, nên hãy thay đổi điều gì đó giữa các lần thử.
• Một khóa mở rộng nhập vào có lịch sử nhưng lại không hiện số dư. Đây chính là cái bẫy pruning. Bộ lập chỉ mục tìm các khoản thanh toán mới bằng cách theo dõi các block mới, nhưng để dựng lại lịch sử của một ví đã có từ trước nghĩa là phải đọc những block mà một node pruned đã xóa mất rồi. Dùng một tài khoản mới cho cửa hàng thì vấn đề này không tồn tại; còn nếu bắt buộc phải nhập lịch sử cũ, bạn cần một node unpruned và một lần rescan.
• “Khách đã trả tiền mà hóa đơn vẫn còn mở.” Thường là do trả thiếu vì phí của ví gửi, một hóa đơn hết hạn trong lúc khoản thanh toán còn nằm chờ xác nhận, hoặc một chính sách xác nhận khắt khe hơn bạn nhớ là mình đã chọn. Cả ba đều là các thiết lập, và cả ba đều là lý do vì sao bạn nên tự thử bằng tiền của chính mình trước.
• Node âm thầm tụt lại phía sau. Một bitcoind bị khựng vẫn phát địa chỉ ra và bỏ lỡ thanh toán mà không hề than phiền gì. Hãy so sánh block height của bạn với bất kỳ nguồn công khai nào theo định kỳ và cảnh báo khi có khoảng lệch; đây không phải điều bạn nên biết lần đầu từ một khách hàng.
• Cập nhật sai thời điểm. btcpay-update.sh khá ngoan, nhưng nó khởi động lại mọi thứ. Hãy chạy nó một cách có chủ đích, không bao giờ tự động, và không bao giờ trong lúc đang bán hàng.
• Địa chỉ dính tai tiếng. Một trang thanh toán trên một IPv4 nằm trong blocklist là một trang thanh toán mà một số mạng doanh nghiệp và bộ lọc mail âm thầm từ chối. Mọi gói ở đây đều đi kèm một địa chỉ riêng không có lịch sử, và đáng để kiểm tra nó trước khi bạn in domain lên bất cứ thứ gì.

Phần mềm loại bỏ một bên trung gian. Nó không loại bỏ phần còn lại của bề mặt lộ diện, và trung thực về điều đó hữu ích hơn nhiều so với thêm một danh sách tính năng nữa.

Domain là điểm yếu. Nó được đăng ký ở đâu đó, nó phân giải công khai, và nó là thứ đầu tiên bất kỳ ai cũng nhìn vào. Một bộ xử lý thanh toán tự lưu trữ trên một hostname đăng ký dưới chính tên bạn tại một registrar ngay trong nước bạn thì đã chuyển được tiền ra khỏi tay bên thứ ba, nhưng lại để nguyên danh tính ở đúng chỗ cũ. Nếu điều đó quan trọng với thứ bạn đang bán, registrar xứng đáng được cân nhắc kỹ ít nhất ngang với nhà cung cấp host.

Khu vực pháp lý là một biến số có thật. Máy chủ đặt ở đâu quyết định lệnh tòa án của ai có thể chạm tới nó và cần bao nhiêu thủ tục mới chạm được. Đó là ma sát và khoảng cách, không phải miễn nhiễm — một điểm mà bài hosting offshore đã nói kỹ, và đáng đọc trước khi chọn một lá cờ thay vì chọn một mạng lưới.

Tài khoản là mắt xích cuối cùng. Thuê máy chủ bằng một địa chỉ email và trả tiền bằng Monero nghĩa là không có sao kê thẻ nào nối trang thanh toán với một ngân hàng — một điều kỳ lạ nếu bỏ sót trong lúc xây một hệ thống mà cả điểm mấu chốt của nó là không cần đến điều đó. Mọi gói ở đây đều no-KYC theo mặc định, và mọi địa điểm đều đi kèm một IPv4 sạch riêng với reverse DNS tùy chỉnh.

Và ranh giới được nói thẳng ra chứ không chỉ ngụ ý. Node, bộ xử lý thanh toán và cửa hàng đều là hạ tầng bình thường và được chào đón ở đây; chính sách sử dụng chấp nhận được ngắn gọn, công khai, và có một giới hạn cứng bên dưới. Việc bạn có cần giấy phép để nhận thanh toán hay không là câu hỏi về việc bạn bán gì và bạn ở đâu, không phải về phần mềm — và đó là câu hỏi dành cho người có chuyên môn, không phải cho một bài hướng dẫn hosting.