Tình hình smart contract của Pi Network: Sau V23, nhà phát triển thực sự có thể làm gì?

V23 đã đưa smart contract Soroban lên Pi mainnet vào tháng 5 năm 2026, đây là bản nâng cấp kỹ thuật lớn nhất của Pi kể từ Open Mainnet. Tuy nhiên, có một khoảng trống mà đội ngũ chính thức chưa bao giờ giải thích rõ ràng giữa việc "smart contract đã lên mainnet" và "nhà phát triển hiện có thể làm gì với smart contract".

Bài viết này tổng hợp các thông tin trực tiếp hiện có, cung cấp một cái nhìn thực tế về tình hình hiện tại cho cả người khai thác thông thường và nhà phát triển.

Dành cho người khai thác thông thường: Pi Network hiện có thể làm gì?

Những điều đã xác nhận có thể làm

Pi SDK: Đăng nhập và Thanh toán Đây là khả năng đã tồn tại từ những ngày đầu của Pi, không liên quan đến việc nâng cấp giao thức. Các App trong Pi Browser có thể cho phép người dùng đăng nhập bằng tài khoản Pi và thanh toán bằng Pi thông qua Pi SDK. Hầu hết các ứng dụng trong hệ sinh thái Pi hiện tại đều hoạt động dựa trên cơ chế này.

Soroban smart contract (về mặt kỹ thuật đã sẵn sàng và trưởng thành hơn so với thông tin trước đây) V23 sau đó, Soroban smart contract đã sẵn sàng về mặt kỹ thuật. Đội ngũ chính thức đã công bố mẫu hợp đồng đầu tiên trên GitHub: hợp đồng đăng ký (PiRC2), với thiết kế khá hoàn chỉnh, bao gồm các chức năng như đăng ký dịch vụ cho người bán, người dùng đăng ký, tự động trừ tiền, thời gian dùng thử, v.v.

OrbitWatch đã xác nhận thêm rằng hợp đồng này không chỉ là một ví dụ trên GitHub – nó đã được triển khai trên Pi Testnet và được đóng gói vào tệp Pi SDK được phát hành chính thức (xem "Lộ trình hai" bên dưới). Tuy nhiên, hiện chưa có thông báo công khai nào từ đội ngũ chính thức về việc liệu nhà phát triển có thể thực sự triển khai hoặc gọi hợp đồng này hay không.

Những điều hiện chưa chắc chắn

Bên thứ ba có thể gọi hoặc triển khai smart contract không? Đội ngũ chính thức đã trả lời rõ ràng trên Developer Discord: chức năng smart contract "chưa được hoàn thiện, hiện chỉ dành cho mục đích nội bộ, sẽ có thông báo thêm khi có tin tức mới". Về mặt kỹ thuật đã khá trưởng thành, nhưng lịch trình mở cửa cho bên ngoài vẫn chưa được biết.

Khi nào token PiRC1 có thể được phát hành trên mainnet? PiRC1 định nghĩa các quy tắc phát hành token hệ sinh thái (phải có sản phẩm trước khi phát hành token), và Pi Launchpad cũng đã xác minh quy trình bằng các token thử nghiệm (IRRA, SLICE). Tuy nhiên, hiện tại chưa có bất kỳ bên thứ ba nào hoàn thành chính thức việc kiểm duyệt PiRC1 và phát hành token thật trên mainnet.

Tóm tắt trong một câu

V23 đã mang đến khả năng "về mặt kỹ thuật là có thể", và mức độ hoàn thiện cao hơn so với thông tin trước đây; nhưng về việc "mở cửa cho bên thứ ba", đội ngũ chính thức đã tuyên bố rõ ràng – chưa đến lúc. Tuy nhiên, OrbitWatch cũng quan sát thấy rằng đã có nhà phát triển tìm ra cách để vận hành smart contract mà không cần chờ đợi đội ngũ chính thức mở cửa (xem giải thích bên dưới).

Dành cho nhà phát triển: Hiện có thể sử dụng những chức năng nào của Pi?

Lộ trình một: Pi SDK (JavaScript)

Đây là lộ trình phát triển trưởng thành nhất và có tài liệu đầy đủ nhất hiện nay.

Những điều có thể làm
→ Pi Sign-in: Cho phép người dùng đăng nhập vào App của bạn bằng tài khoản Pi
→ Pi Payment: Cho phép người dùng thanh toán cho App của bạn bằng Pi
 
Hạn chế
→ Hướng dẫn trong tài liệu công khai của đội ngũ chính thức chỉ bao gồm Pi.init({ version: "2.0" })
→ Phiên bản này không thể gọi các chức năng liên quan đến smart contract
→ Không thể phát hành token hệ sinh thái của riêng bạn

Nếu bạn chỉ muốn tạo một App có chức năng đăng nhập và thanh toán trong Pi Browser, Pi SDK (version 2.0) là lựa chọn đáng tin cậy nhất hiện nay.

Lộ trình hai: Soroban smart contract (Rust + dịch vụ SmartContract tích hợp trong SDK)

Đây là lộ trình mới mà V23 mang lại. Xác minh mới nhất của OrbitWatch cho thấy mức độ hoàn thiện của lộ trình này cao hơn so với thông tin trước đây, nhưng vẫn chưa mở cửa cho bên thứ ba.

Những phần đã xác nhận tồn tại, nhưng chưa được ghi vào tài liệu chính thức:

Pi Browser sẽ tự động tải tệp công khai sdk.minepi.com/pi-sdk.js. Sau khi OrbitWatch xem xét mã nguồn đã phát hành này, họ xác nhận:

Dịch vụ SmartContract đã được bao gồm trong Pi SDK
→ Cần truyền version: "3.0" khi khởi tạo (tài liệu chính thức chỉ hướng dẫn "2.0")
→ Cung cấp các phương thức submitTransaction() và pollTransaction()
→ Đã đóng gói hai mô-đun con là Subscription và NativeToken
→ Testnet RPC URL: https://rpc.testnet.minepi.com
→ Network passphrase: Pi Testnet
→ Địa chỉ hợp đồng Testnet đã được tích hợp sẵn trong mã SDK

Nói cách khác, thông tin trước đây trên trang này nói rằng "các tham số kết nối Soroban RPC của Pi Testnet chưa được đội ngũ chính thức công khai" giờ đã được cập nhật – những tham số này thực sự tồn tại trong tệp SDK đã phát hành, chỉ là chúng không được ghi vào các tài liệu công khai như pi-platform-docs.

Tuy nhiên, thông qua lộ trình SDK chính thức này, các cuộc gọi từ bên thứ ba hiện sẽ bị từ chối. Đã có nhà phát triển báo cáo kết quả thử nghiệm trên Developer Discord: gọi Pi.SmartContract.submitTransaction() sẽ đến native bridge, nhưng trả về thông báo "App unauthorized to call this message". Người liên hệ chính thức đã xác nhận rằng chức năng này "chưa được hoàn thiện, chỉ dành cho mục đích nội bộ".

Ví dụ trên GitHub chính thức:

github.com/PiNetwork/SmartContracts
→ Chỉ có một thư mục: contracts/subscription
→ Trang README chính chỉ có một dòng tiêu đề, không có hướng dẫn bắt đầu
→ Toàn bộ repo chỉ có 2 commits

Nội dung của hợp đồng subscription:

Hợp đồng này (tương ứng với thông số kỹ thuật PiRC2, và cũng tương ứng với mô-đun Subscription trong SDK) có thiết kế khá hoàn chỉnh:

Những điều người bán có thể làm
→ register_service: Tạo dịch vụ đăng ký (thiết lập giá, chu kỳ, thời gian dùng thử)
→ process: Thu tiền hàng loạt từ những người đăng ký đã đến hạn
 
Những điều người dùng có thể làm
→ subscribe: Đăng ký dịch vụ (có thể thiết lập tự động gia hạn)
→ cancel: Hủy tự động gia hạn
→ toggle_auto_renew: Chuyển đổi trạng thái tự động gia hạn
→ extend_subscription: Gia hạn ủy quyền token
 
Hàm truy vấn (gọi miễn phí)
→ get_service / get_subscription / is_subscription_active, v.v.

Hợp đồng sử dụng chế độ trừ tiền token approve + transfer_from của Stellar, tiền vẫn nằm trong ví người dùng cho đến khi thực sự trừ tiền mới chuyển đi, không cần khóa trước. Đây không chỉ là mã ví dụ – OrbitWatch xác nhận hợp đồng này đã thực sự được triển khai trên Pi Testnet.

Một quan sát mới: Đội ngũ chính thức khóa "cổng SDK", không phải "bản thân hợp đồng trên chuỗi"

Khi OrbitWatch xác minh các tin đồn trong cộng đồng, họ đã tìm thấy một hợp đồng escrow Soroban đang hoạt động thực sự trên Pi Testnet (có tính chất tương tự như việc ký quỹ tiền "phí vệ sinh khi trả phòng" trong ứng dụng đặt phòng), và đã trực tiếp truy vấn qua Testnet RPC để xác minh sự tồn tại và lịch sử hoạt động của nó.

Cách xác minh: Đầu tiên, sử dụng phương thức getEvents để xác nhận địa chỉ hợp đồng đó có nhiều bản ghi sự kiện thực tế (các trạng thái như created, funded, auto_released, v.v.), sau đó sử dụng phương thức getTransaction để tra cứu nội dung đầy đủ của một giao dịch cụ thể, và sau khi giải mã envelopeXdr đã xác nhận các chi tiết quan trọng:

Tài khoản khởi tạo giao dịch này (source_account)
→ Là một địa chỉ ví cố định (được suy đoán là tài khoản
  escrow/backend của ứng dụng), không phải tài khoản
  riêng của người dùng (guest) hoặc chủ nhà (host)
→ Nói cách khác, giao dịch này không phải do người dùng
  thao tác qua Pi Browser, kích hoạt cuộc gọi Pi.SmartContract SDK,
  mà là hệ thống của nhà phát triển trực tiếp ký và gửi giao dịch
  đến Soroban RPC

Điều này đã giải quyết một mâu thuẫn trước đây: đội ngũ chính thức rõ ràng nói rằng smart contract "chỉ dành cho mục đích nội bộ", nhưng thực sự có nhà phát triển đang vận hành hợp đồng trên Testnet. Câu trả lời là – nhà phát triển này không thông qua Pi.SmartContract SDK tích hợp trong Pi Browser (lộ trình đó vẫn sẽ bị chặn bởi unauthorized), mà là bỏ qua lớp này, trực tiếp sử dụng chuỗi công cụ Soroban tiêu chuẩn để thao tác với hợp đồng đã triển khai.

Về mặt kỹ thuật, điều này hoàn toàn hợp lý: một khi hợp đồng Soroban được triển khai trên Testnet, về bản chất nó là một đối tượng công khai trên chuỗi, bất kỳ ai có tài khoản Testnet đều có thể trực tiếp gọi bằng Stellar/Soroban SDK tiêu chuẩn, điều này không cần thông qua native bridge của Pi Browser, và đương nhiên sẽ không kích hoạt kiểm tra quyền hạn mà đội ngũ chính thức của Pi đã thiết lập ở lớp SDK.

Điều này có nghĩa là phạm vi hạn chế hiện tại của đội ngũ chính thức, chính xác hơn so với những gì chúng ta hiểu ban đầu:

Những gì đội ngũ chính thức khóa
→ Quyền gọi Pi Browser tích hợp Pi.SmartContract SDK
  (đây là cổng mà đội ngũ chính thức có thể kiểm soát)
 
Những gì đội ngũ chính thức không và không thể khóa
→ Trực tiếp thao tác với bản thân hợp đồng đã triển khai trên Testnet
  bằng công cụ Soroban tiêu chuẩn (đây là bản chất của dữ liệu công khai trên chuỗi,
  không qua Pi Browser thì không bị kiểm soát bởi lớp quyền hạn này)

Đối với nhà phát triển, điều này có nghĩa là: nếu bạn sẵn sàng bỏ qua Pi SDK, tự quản lý khóa tài khoản, và trực tiếp gửi giao dịch đến Soroban RPC, thì việc thao tác smart contract trên Testnet về mặt kỹ thuật là khả thi, nhưng làm như vậy không thông qua lộ trình SDK được đội ngũ chính thức công nhận, và hiện chưa có bất kỳ tuyên bố nào về việc liệu đội ngũ chính thức có ủng hộ cách làm này hay không.

So sánh định vị của hai lộ trình

                    Pi SDK (JS, v2.0)   SmartContract (SDK v3.0)
──────────────────────────────────────────────────────────────
Mục đích chính     Đăng nhập + Thanh toán Smart contract / Đăng ký / Token
Ngôn ngữ phát triển JavaScript          Đóng gói JavaScript SDK + Hợp đồng Rust
Mức độ hoàn chỉnh tài liệu chính thức Hoàn chỉnh            Chưa được ghi vào tài liệu công khai, nhưng đã tồn tại trong SDK
Kết nối Testnet    Không áp dụng       Đã biết (RPC URL, passphrase đã xác nhận)
Gọi qua SDK chính thức
                   Có                  Không (unauthorized)
Thao tác trực tiếp với hợp đồng đã triển khai (bỏ qua SDK)
                   Không áp dụng       Về mặt kỹ thuật khả thi, lập trường chính thức chưa rõ
Có sẵn trên Mainnet Có                  Chưa biết
Ảnh hưởng của nâng cấp giao thức
                   Không               Liên quan trực tiếp
Ngưỡng gia nhập    Thấp                Về mặt kỹ thuật đã sẵn sàng, lộ trình được chính thức công nhận chưa mở

Những khoảng trống chưa được đội ngũ chính thức giải thích

Dưới đây là những câu hỏi mà OrbitWatch không tìm thấy lịch trình chính thức từ đội ngũ chính thức, được liệt kê trực tiếp:

Khi nào chức năng smart contract sẽ được mở cho bên thứ ba (thông qua lộ trình SDK chính thức)? Đội ngũ chính thức chỉ nói "chưa được hoàn thiện".
Việc nhà phát triển bỏ qua Pi SDK, trực tiếp thao tác với hợp đồng đã triển khai trên Testnet, đội ngũ chính thức có công nhận hay cho phép không?
Tiến độ kiểm toán chính thức và thời gian ra mắt Mainnet của hợp đồng đăng ký PiRC2?
Khi nào bên thứ ba có thể chính thức phát hành token trên mainnet thông qua quy trình PiRC1?
Tại sao dịch vụ SmartContract đã có mức độ hoàn thiện khá cao nhưng lại chọn không ghi vào tài liệu công khai? Những câu hỏi này không phải là điều OrbitWatch có thể trả lời, chỉ có thể ghi chú lại một cách trung thực. Nếu đội ngũ chính thức có bất kỳ tuyên bố chính thức nào về các vấn đề trên, chúng tôi sẽ cập nhật trang này ngay lập tức.

Đọc thêm

Nguồn dữ liệu: PiNetwork/SmartContracts GitHub repo (quan sát trực tiếp), sdk.minepi.com/pi-sdk.js (tệp SDK được đội ngũ chính thức công khai, quan sát trực tiếp), Pi Network Developer Discord (thảo luận công khai trên kênh dev-questions), Pi Testnet Soroban RPC (rpc.testnet.minepi.com, truy vấn trực tiếp getEvents/getTransaction), Pi-Defi-world/pirc-smart-contracts-explainer GitHub repo (bên thứ ba, không chính thức), tài liệu Pi Network Horizon API. Mọi phân tích không cấu thành lời khuyên đầu tư. OrbitWatch là một trạm quan sát hệ sinh thái Pi Network độc lập, không có bất kỳ liên hệ nào với đội ngũ chính thức của Pi Network.