Lữ Khách Web3
338 Beiträge
Lữ Khách Web3
Melden
Nutzer blockieren
Lữ Khách Onchain - Web3
Trade eröffnen
Hochfrequenz-Trader
3.8 Monate
50 Following
154 Follower
431 Like gegeben
Beiträge
Portfolio
Übersetzung ansehen
Có một điểm khiến tôi dừng lại khi đọc về Dusk Network đó là: nếu blockchain vốn được xây dựng quanh tính minh bạch tại sao một mạng hướng tới tài chính tổ chức lại phải đặt privacy ở vị trí khá quan trọng?
Ban đầu tôi nghĩ đây có thể chỉ là cách định vị sản phẩm nhưng khi đọc tài liệu của Dusk kỹ hơn, vấn đề bắt đầu rõ hơn. Dusk mô tả các ứng dụng tài chính cần bảo vệ balance, position, counterparty và business logic thay vì đưa toàn bộ trạng thái lên public ledger.
Tôi tiếp tục kiểm tra cách họ xử lý vấn đề này. Dusk không đơn giản nói “ẩn dữ liệu”. Kiến trúc hiện tại kết hợp confidential transfers, zero-knowledge proofs và selective disclosure. Một số thông tin có thể được giữ kín trên chain trong khi thông tin cần thiết vẫn có thể được chứng minh hoặc tiết lộ có kiểm soát.
Điều tôi không ngờ là privacy ở đây không được đặt đối lập hoàn toàn với compliance. Citadel chẳng hạn, sử dụng selective disclosure để chứng minh thuộc tính như residency, age bracket hoặc accreditation mà không nhất thiết phải công khai toàn bộ dữ liệu.
Khoan, điều này vẫn chưa đủ để nói rằng Dusk đã giải quyết bài toán dữ liệu nhạy cảm của tài chính tổ chức. Privacy còn phụ thuộc vào cách ứng dụng triển khai và những metadata nào vẫn có thể bị lộ.
Nhưng sau khi đọc sâu hơn tôi bắt đầu nhìn câu hỏi khác đi: với tài chính on chain liệu vấn đề không phải là “privacy hay transparency” mà là ai được nhìn thấy dữ liệu nào, trong hoàn cảnh nào?
#dusk $DUSK @Dusk_Foundation $BTC
Có một điểm khiến tôi dừng lại khi đọc về Dusk Network đó là: nếu blockchain vốn được xây dựng quanh tính minh bạch tại sao một mạng hướng tới tài chính tổ chức lại phải đặt privacy ở vị trí khá quan trọng?
Ban đầu tôi nghĩ đây có thể chỉ là cách định vị sản phẩm nhưng khi đọc tài liệu của Dusk kỹ hơn, vấn đề bắt đầu rõ hơn. Dusk mô tả các ứng dụng tài chính cần bảo vệ balance, position, counterparty và business logic thay vì đưa toàn bộ trạng thái lên public ledger.
Tôi tiếp tục kiểm tra cách họ xử lý vấn đề này. Dusk không đơn giản nói “ẩn dữ liệu”. Kiến trúc hiện tại kết hợp confidential transfers, zero-knowledge proofs và selective disclosure. Một số thông tin có thể được giữ kín trên chain trong khi thông tin cần thiết vẫn có thể được chứng minh hoặc tiết lộ có kiểm soát.
Điều tôi không ngờ là privacy ở đây không được đặt đối lập hoàn toàn với compliance. Citadel chẳng hạn, sử dụng selective disclosure để chứng minh thuộc tính như residency, age bracket hoặc accreditation mà không nhất thiết phải công khai toàn bộ dữ liệu.
Khoan, điều này vẫn chưa đủ để nói rằng Dusk đã giải quyết bài toán dữ liệu nhạy cảm của tài chính tổ chức. Privacy còn phụ thuộc vào cách ứng dụng triển khai và những metadata nào vẫn có thể bị lộ.
Nhưng sau khi đọc sâu hơn tôi bắt đầu nhìn câu hỏi khác đi: với tài chính on chain liệu vấn đề không phải là “privacy hay transparency” mà là ai được nhìn thấy dữ liệu nào, trong hoàn cảnh nào?
#dusk $DUSK @Dusk $BTC
Ban đầu tôi nghĩ đây có thể chỉ là cách định vị sản phẩm nhưng khi đọc tài liệu của Dusk kỹ hơn, vấn đề bắt đầu rõ hơn. Dusk mô tả các ứng dụng tài chính cần bảo vệ balance, position, counterparty và business logic thay vì đưa toàn bộ trạng thái lên public ledger.
Tôi tiếp tục kiểm tra cách họ xử lý vấn đề này. Dusk không đơn giản nói “ẩn dữ liệu”. Kiến trúc hiện tại kết hợp confidential transfers, zero-knowledge proofs và selective disclosure. Một số thông tin có thể được giữ kín trên chain trong khi thông tin cần thiết vẫn có thể được chứng minh hoặc tiết lộ có kiểm soát.
Điều tôi không ngờ là privacy ở đây không được đặt đối lập hoàn toàn với compliance. Citadel chẳng hạn, sử dụng selective disclosure để chứng minh thuộc tính như residency, age bracket hoặc accreditation mà không nhất thiết phải công khai toàn bộ dữ liệu.
Khoan, điều này vẫn chưa đủ để nói rằng Dusk đã giải quyết bài toán dữ liệu nhạy cảm của tài chính tổ chức. Privacy còn phụ thuộc vào cách ứng dụng triển khai và những metadata nào vẫn có thể bị lộ.
Nhưng sau khi đọc sâu hơn tôi bắt đầu nhìn câu hỏi khác đi: với tài chính on chain liệu vấn đề không phải là “privacy hay transparency” mà là ai được nhìn thấy dữ liệu nào, trong hoàn cảnh nào?
#dusk $DUSK @Dusk $BTC
2
1
236
Übersetzung ansehen
Có gì đó khiến tôi dừng lại khi đọc docs của Dusk. Họ liên tục đặt privacy, compliance và settlement vào cùng một stack như thể ba thứ này không thể tách rời.
Dusk đang xây L1 cho regulated finance. DuskDS làm lớp settlement và data availability với finality deterministic qua Succinct Attestation. Trên đó có dual transaction model: Phoenix cho shielded, Moonlight cho transparent. Citadel lo selective disclosure. DuskEVM và DuskVM chạy execution nhưng tất cả đều settle về cùng một base.
Tôi muốn xem liệu việc gộp ba thứ này có thực sự xuất phát từ yêu cầu kỹ thuật hay chỉ là cách định vị cho RWA. Tôi đọc core components, transaction models rồi đối chiếu với cách họ mô tả workflow phát hành và settle chứng khoán.
Hóa ra architecture modular nhưng vẫn buộc privacy và compliance logic nằm sát settlement layer. Phoenix dùng ZK để che amount và participant trong khi vẫn cho phép audit path. Compliance không phải add-on ở app mà được thiết kế để chạy song song với finality.
Khoan, có lẽ đây chỉ là lựa chọn triển khai cho institutional workflow chứ không phải định luật bắt buộc. Nhiều chain khác tách privacy ra L2 hoặc side system, settlement giữ public. Dusk chọn gộp vì họ nhắm vào regulated assets, nơi data nhạy cảm và finality phải đi cùng nhau để tránh handoff giữa nhiều hệ thống.
Nhìn rộng hơn ngành đang thấy pattern tương tự ở vài protocol RWA khác: marketing nhấn mạnh “privacy + compliance native” trong khi execution thực tế vẫn phụ thuộc vào license bên ngoài và tooling quen thuộc.
Liệu settlement có thực sự cần privacy embedded ở base layer hay chỉ cần interface đủ tốt để các lớp trên tự quyết?
#dusk $DUSK @Dusk_Foundation $BTC
Có gì đó khiến tôi dừng lại khi đọc docs của Dusk. Họ liên tục đặt privacy, compliance và settlement vào cùng một stack như thể ba thứ này không thể tách rời.
Dusk đang xây L1 cho regulated finance. DuskDS làm lớp settlement và data availability với finality deterministic qua Succinct Attestation. Trên đó có dual transaction model: Phoenix cho shielded, Moonlight cho transparent. Citadel lo selective disclosure. DuskEVM và DuskVM chạy execution nhưng tất cả đều settle về cùng một base.
Tôi muốn xem liệu việc gộp ba thứ này có thực sự xuất phát từ yêu cầu kỹ thuật hay chỉ là cách định vị cho RWA. Tôi đọc core components, transaction models rồi đối chiếu với cách họ mô tả workflow phát hành và settle chứng khoán.
Hóa ra architecture modular nhưng vẫn buộc privacy và compliance logic nằm sát settlement layer. Phoenix dùng ZK để che amount và participant trong khi vẫn cho phép audit path. Compliance không phải add-on ở app mà được thiết kế để chạy song song với finality.
Khoan, có lẽ đây chỉ là lựa chọn triển khai cho institutional workflow chứ không phải định luật bắt buộc. Nhiều chain khác tách privacy ra L2 hoặc side system, settlement giữ public. Dusk chọn gộp vì họ nhắm vào regulated assets, nơi data nhạy cảm và finality phải đi cùng nhau để tránh handoff giữa nhiều hệ thống.
Nhìn rộng hơn ngành đang thấy pattern tương tự ở vài protocol RWA khác: marketing nhấn mạnh “privacy + compliance native” trong khi execution thực tế vẫn phụ thuộc vào license bên ngoài và tooling quen thuộc.
Liệu settlement có thực sự cần privacy embedded ở base layer hay chỉ cần interface đủ tốt để các lớp trên tự quyết?
#dusk $DUSK @Dusk $BTC
Dusk đang xây L1 cho regulated finance. DuskDS làm lớp settlement và data availability với finality deterministic qua Succinct Attestation. Trên đó có dual transaction model: Phoenix cho shielded, Moonlight cho transparent. Citadel lo selective disclosure. DuskEVM và DuskVM chạy execution nhưng tất cả đều settle về cùng một base.
Tôi muốn xem liệu việc gộp ba thứ này có thực sự xuất phát từ yêu cầu kỹ thuật hay chỉ là cách định vị cho RWA. Tôi đọc core components, transaction models rồi đối chiếu với cách họ mô tả workflow phát hành và settle chứng khoán.
Hóa ra architecture modular nhưng vẫn buộc privacy và compliance logic nằm sát settlement layer. Phoenix dùng ZK để che amount và participant trong khi vẫn cho phép audit path. Compliance không phải add-on ở app mà được thiết kế để chạy song song với finality.
Khoan, có lẽ đây chỉ là lựa chọn triển khai cho institutional workflow chứ không phải định luật bắt buộc. Nhiều chain khác tách privacy ra L2 hoặc side system, settlement giữ public. Dusk chọn gộp vì họ nhắm vào regulated assets, nơi data nhạy cảm và finality phải đi cùng nhau để tránh handoff giữa nhiều hệ thống.
Nhìn rộng hơn ngành đang thấy pattern tương tự ở vài protocol RWA khác: marketing nhấn mạnh “privacy + compliance native” trong khi execution thực tế vẫn phụ thuộc vào license bên ngoài và tooling quen thuộc.
Liệu settlement có thực sự cần privacy embedded ở base layer hay chỉ cần interface đủ tốt để các lớp trên tự quyết?
#dusk $DUSK @Dusk $BTC
1
2
224
Verifiziert
Etwas, das mich beim Lesen der Dusk-Docs innehalten ließ. Die meisten L1-Privacy-Projekte sprechen über „shielded transactions“, aber hier betonen sie „selective disclosure“ und „access control“ – direkt schon ab Protokoll.
Dusk ist eine öffentliche, permissionless Layer-1, die sich auf die native Emission digitaler Wertpapiere und regulierter Assets konzentriert. Sie haben Partnerschaften mit NPEX (MTF, Broker, ECSP-Lizenzen), ein duales Modell Phoenix/Moonlight, Citadel für Identität und treiben DuskEVM voran. Das Mainnet läuft bereits, die Docs und GitHub Rusk werden kontinuierlich aktualisiert. Ich möchte sehen, ob die zugrunde liegende Architektur wirklich anders ist als Projekte, die Compliance nur auf der Application-Ebene „dran kleben“. Lese ich mir Overview und die Core Components durch und stelle sie anschließend den News zu NPEX und DLT-TSS gegenüber. Dabei zeigt sich: Compliance ist im Protokoll eingebettet – Eligibility, Transfer Restriction, Forced Transfer sowie die Aktionärs-Registry, die bei Bedarf selektiv entschlüsselt werden kann.
Privacy ist nicht absolutes Anonymitäts-„Verstecktsein“, sondern „private by default, auditable when required“. Das ist ein anderer Ansatz als bei den meisten aktuellen DeFi-Projekten.
Vielleicht interpretiere ich das aber auch zu stark. Die NPEX-Lizenzen gehören dem Partner, nicht dazu, dass das Protokoll alles selbst vollständig besitzt. DLT-TSS ist weiterhin in Arbeit; das könnte nur die Art sein, wie sie es für den europäischen Markt umsetzen. Viele Protokolle wechseln ohnehin gerade von purem DeFi hin zu regulierter Infrastruktur. Marketing kommt oft dem realen Produkt voraus, während die institutionelle Adoption viel langsamer hinter der Story herläuft. Bewerten wir gerade die Narrative von „regulated DeFi“ – oder messen wir daran, wie viel echtes Asset-Volumen tatsächlich onchain abgewickelt (settled) wird?
#dusk $DUSK @Dusk_Foundation $BTC
Etwas, das mich beim Lesen der Dusk-Docs innehalten ließ. Die meisten L1-Privacy-Projekte sprechen über „shielded transactions“, aber hier betonen sie „selective disclosure“ und „access control“ – direkt schon ab Protokoll.
Dusk ist eine öffentliche, permissionless Layer-1, die sich auf die native Emission digitaler Wertpapiere und regulierter Assets konzentriert. Sie haben Partnerschaften mit NPEX (MTF, Broker, ECSP-Lizenzen), ein duales Modell Phoenix/Moonlight, Citadel für Identität und treiben DuskEVM voran. Das Mainnet läuft bereits, die Docs und GitHub Rusk werden kontinuierlich aktualisiert. Ich möchte sehen, ob die zugrunde liegende Architektur wirklich anders ist als Projekte, die Compliance nur auf der Application-Ebene „dran kleben“. Lese ich mir Overview und die Core Components durch und stelle sie anschließend den News zu NPEX und DLT-TSS gegenüber. Dabei zeigt sich: Compliance ist im Protokoll eingebettet – Eligibility, Transfer Restriction, Forced Transfer sowie die Aktionärs-Registry, die bei Bedarf selektiv entschlüsselt werden kann.
Privacy ist nicht absolutes Anonymitäts-„Verstecktsein“, sondern „private by default, auditable when required“. Das ist ein anderer Ansatz als bei den meisten aktuellen DeFi-Projekten.
Vielleicht interpretiere ich das aber auch zu stark. Die NPEX-Lizenzen gehören dem Partner, nicht dazu, dass das Protokoll alles selbst vollständig besitzt. DLT-TSS ist weiterhin in Arbeit; das könnte nur die Art sein, wie sie es für den europäischen Markt umsetzen. Viele Protokolle wechseln ohnehin gerade von purem DeFi hin zu regulierter Infrastruktur. Marketing kommt oft dem realen Produkt voraus, während die institutionelle Adoption viel langsamer hinter der Story herläuft. Bewerten wir gerade die Narrative von „regulated DeFi“ – oder messen wir daran, wie viel echtes Asset-Volumen tatsächlich onchain abgewickelt (settled) wird?
#dusk $DUSK @Dusk $BTC
Dusk ist eine öffentliche, permissionless Layer-1, die sich auf die native Emission digitaler Wertpapiere und regulierter Assets konzentriert. Sie haben Partnerschaften mit NPEX (MTF, Broker, ECSP-Lizenzen), ein duales Modell Phoenix/Moonlight, Citadel für Identität und treiben DuskEVM voran. Das Mainnet läuft bereits, die Docs und GitHub Rusk werden kontinuierlich aktualisiert. Ich möchte sehen, ob die zugrunde liegende Architektur wirklich anders ist als Projekte, die Compliance nur auf der Application-Ebene „dran kleben“. Lese ich mir Overview und die Core Components durch und stelle sie anschließend den News zu NPEX und DLT-TSS gegenüber. Dabei zeigt sich: Compliance ist im Protokoll eingebettet – Eligibility, Transfer Restriction, Forced Transfer sowie die Aktionärs-Registry, die bei Bedarf selektiv entschlüsselt werden kann.
Privacy ist nicht absolutes Anonymitäts-„Verstecktsein“, sondern „private by default, auditable when required“. Das ist ein anderer Ansatz als bei den meisten aktuellen DeFi-Projekten.
Vielleicht interpretiere ich das aber auch zu stark. Die NPEX-Lizenzen gehören dem Partner, nicht dazu, dass das Protokoll alles selbst vollständig besitzt. DLT-TSS ist weiterhin in Arbeit; das könnte nur die Art sein, wie sie es für den europäischen Markt umsetzen. Viele Protokolle wechseln ohnehin gerade von purem DeFi hin zu regulierter Infrastruktur. Marketing kommt oft dem realen Produkt voraus, während die institutionelle Adoption viel langsamer hinter der Story herläuft. Bewerten wir gerade die Narrative von „regulated DeFi“ – oder messen wir daran, wie viel echtes Asset-Volumen tatsächlich onchain abgewickelt (settled) wird?
#dusk $DUSK @Dusk $BTC
280
Es gibt einen Punkt, der mich beim Lesen über STOX innehalten ließ. Anfangs konnte ich es ziemlich leicht in die Kategorie DEX einordnen: ein Ort, an dem man On-Chain-Vermögenswerte handeln kann. Doch als ich mir die Unterlagen von Dusk genauer ansah, merkte ich, dass diese Beschreibung um einiges zu kurz greift.
STOX wurde von Dusk früher als interner Code-Namen für eine Trading-Plattform bezeichnet. Ziel war es, regulierte Assets auf die Kette zu bringen und es Anlegern zu ermöglichen, damit zu handeln. Heute heißt dieses Produkt Dusk Trade.
Ich habe mir dann den Teil hinter dem eigentlichen Handel genauer angesehen. Dusk Trade geht nicht nur auf „Kaufen“ und „Verkaufen“ ein; die aktuellen Dokumente führen außerdem Investor Onboarding, Eligibility, Wallet Binding, Controlled Transfers, Payment Coordination und Settlement auf.
Ab hier musste ich mein ursprüngliches Verständnis korrigieren. Der Unterschied scheint weniger darin zu liegen, ob es „Token-Handel“ gibt oder nicht, sondern vielmehr in den Regeln, die zusammen mit dem Handel beachtet werden müssen, wenn es sich bei den Assets um regulierte Vermögenswerte handelt.
Aber ich möchte es auch nicht überdramatisieren. Dusk Trade wird noch gebaut, daher lässt sich aus der aktuell veröffentlichten Architektur noch kein abschließendes Urteil über die tatsächliche Marktwirkung ableiten.
Was ich jedoch wirklich bemerkenswert finde, ist: Wenn Eligibility, Transfer-Regeln und Settlement zu einem Bestandteil des Trading-Workflows werden, reicht dann der Begriff „DEX“ noch aus, um dieses Produkt zu beschreiben?
#dusk $DUSK @Dusk_Foundation $BTC
Es gibt einen Punkt, der mich beim Lesen über STOX innehalten ließ. Anfangs konnte ich es ziemlich leicht in die Kategorie DEX einordnen: ein Ort, an dem man On-Chain-Vermögenswerte handeln kann. Doch als ich mir die Unterlagen von Dusk genauer ansah, merkte ich, dass diese Beschreibung um einiges zu kurz greift.
STOX wurde von Dusk früher als interner Code-Namen für eine Trading-Plattform bezeichnet. Ziel war es, regulierte Assets auf die Kette zu bringen und es Anlegern zu ermöglichen, damit zu handeln. Heute heißt dieses Produkt Dusk Trade.
Ich habe mir dann den Teil hinter dem eigentlichen Handel genauer angesehen. Dusk Trade geht nicht nur auf „Kaufen“ und „Verkaufen“ ein; die aktuellen Dokumente führen außerdem Investor Onboarding, Eligibility, Wallet Binding, Controlled Transfers, Payment Coordination und Settlement auf.
Ab hier musste ich mein ursprüngliches Verständnis korrigieren. Der Unterschied scheint weniger darin zu liegen, ob es „Token-Handel“ gibt oder nicht, sondern vielmehr in den Regeln, die zusammen mit dem Handel beachtet werden müssen, wenn es sich bei den Assets um regulierte Vermögenswerte handelt.
Aber ich möchte es auch nicht überdramatisieren. Dusk Trade wird noch gebaut, daher lässt sich aus der aktuell veröffentlichten Architektur noch kein abschließendes Urteil über die tatsächliche Marktwirkung ableiten.
Was ich jedoch wirklich bemerkenswert finde, ist: Wenn Eligibility, Transfer-Regeln und Settlement zu einem Bestandteil des Trading-Workflows werden, reicht dann der Begriff „DEX“ noch aus, um dieses Produkt zu beschreiben?
#dusk $DUSK @Dusk $BTC
STOX wurde von Dusk früher als interner Code-Namen für eine Trading-Plattform bezeichnet. Ziel war es, regulierte Assets auf die Kette zu bringen und es Anlegern zu ermöglichen, damit zu handeln. Heute heißt dieses Produkt Dusk Trade.
Ich habe mir dann den Teil hinter dem eigentlichen Handel genauer angesehen. Dusk Trade geht nicht nur auf „Kaufen“ und „Verkaufen“ ein; die aktuellen Dokumente führen außerdem Investor Onboarding, Eligibility, Wallet Binding, Controlled Transfers, Payment Coordination und Settlement auf.
Ab hier musste ich mein ursprüngliches Verständnis korrigieren. Der Unterschied scheint weniger darin zu liegen, ob es „Token-Handel“ gibt oder nicht, sondern vielmehr in den Regeln, die zusammen mit dem Handel beachtet werden müssen, wenn es sich bei den Assets um regulierte Vermögenswerte handelt.
Aber ich möchte es auch nicht überdramatisieren. Dusk Trade wird noch gebaut, daher lässt sich aus der aktuell veröffentlichten Architektur noch kein abschließendes Urteil über die tatsächliche Marktwirkung ableiten.
Was ich jedoch wirklich bemerkenswert finde, ist: Wenn Eligibility, Transfer-Regeln und Settlement zu einem Bestandteil des Trading-Workflows werden, reicht dann der Begriff „DEX“ noch aus, um dieses Produkt zu beschreiben?
#dusk $DUSK @Dusk $BTC
207
Ich begann, Dusk Network mit einer ziemlich einfachen Frage zu lesen: Wenn RWA tatsächlich auf die Blockchain gebracht werden, was muss diese Blockchain dann außer der bloßen Erfassung von Token eigentlich leisten?
Diese Frage ließ mich das Problem anders betrachten: Tokenisierung ist nur der erste Schritt. Nachdem ein Vermögenswert on-chain repräsentiert wurde, gibt es immer noch Dinge zu klären: Wer darf handeln, wie werden Transaktionen abgewickelt, ob Asset-Leg und Payment-Leg synchronisiert sind und schließlich, wo das Eigentum abgewickelt wird.
Deshalb wollte ich, statt mit der Frage zu beginnen, „ob Dusk eine Blockchain für RWA ist“, zuerst seine Architektur prüfen.
In den Unterlagen von Dusk übernimmt DuskDS Konsens, Finalität und Data Availability von Dusk L1, während DuskEVM eine EVM-kompatible Umgebung für Anwendungen bereitstellt.
Bemerkenswert ist, dass Dusk außerdem eine Market-Infrastruktur mit den Schritten Onboarding, Transferkontrollen, Asset-/Payment-Koordination und Settlement beschreibt.
An diesem Punkt begann ich einen anderen Ansatz zu sehen: RWA brauchen nicht nur einen Ort zur Ausgabe von Token, sondern eine Schicht, die den gesamten Transaktionslebenszyklus verarbeitet; dennoch muss ich eine Frage offenlassen: Eine passende Architektur bedeutet noch nicht automatisch tatsächliche Adoption.
Baut Dusk also بالفعل eine Settlement-Infrastruktur auf, oder nur das Fundament dafür?
#dusk $DUSK @Dusk_Foundation $BTC
Ich begann, Dusk Network mit einer ziemlich einfachen Frage zu lesen: Wenn RWA tatsächlich auf die Blockchain gebracht werden, was muss diese Blockchain dann außer der bloßen Erfassung von Token eigentlich leisten?
Diese Frage ließ mich das Problem anders betrachten: Tokenisierung ist nur der erste Schritt. Nachdem ein Vermögenswert on-chain repräsentiert wurde, gibt es immer noch Dinge zu klären: Wer darf handeln, wie werden Transaktionen abgewickelt, ob Asset-Leg und Payment-Leg synchronisiert sind und schließlich, wo das Eigentum abgewickelt wird.
Deshalb wollte ich, statt mit der Frage zu beginnen, „ob Dusk eine Blockchain für RWA ist“, zuerst seine Architektur prüfen.
In den Unterlagen von Dusk übernimmt DuskDS Konsens, Finalität und Data Availability von Dusk L1, während DuskEVM eine EVM-kompatible Umgebung für Anwendungen bereitstellt.
Bemerkenswert ist, dass Dusk außerdem eine Market-Infrastruktur mit den Schritten Onboarding, Transferkontrollen, Asset-/Payment-Koordination und Settlement beschreibt.
An diesem Punkt begann ich einen anderen Ansatz zu sehen: RWA brauchen nicht nur einen Ort zur Ausgabe von Token, sondern eine Schicht, die den gesamten Transaktionslebenszyklus verarbeitet; dennoch muss ich eine Frage offenlassen: Eine passende Architektur bedeutet noch nicht automatisch tatsächliche Adoption.
Baut Dusk also بالفعل eine Settlement-Infrastruktur auf, oder nur das Fundament dafür?
#dusk $DUSK @Dusk $BTC
Diese Frage ließ mich das Problem anders betrachten: Tokenisierung ist nur der erste Schritt. Nachdem ein Vermögenswert on-chain repräsentiert wurde, gibt es immer noch Dinge zu klären: Wer darf handeln, wie werden Transaktionen abgewickelt, ob Asset-Leg und Payment-Leg synchronisiert sind und schließlich, wo das Eigentum abgewickelt wird.
Deshalb wollte ich, statt mit der Frage zu beginnen, „ob Dusk eine Blockchain für RWA ist“, zuerst seine Architektur prüfen.
In den Unterlagen von Dusk übernimmt DuskDS Konsens, Finalität und Data Availability von Dusk L1, während DuskEVM eine EVM-kompatible Umgebung für Anwendungen bereitstellt.
Bemerkenswert ist, dass Dusk außerdem eine Market-Infrastruktur mit den Schritten Onboarding, Transferkontrollen, Asset-/Payment-Koordination und Settlement beschreibt.
An diesem Punkt begann ich einen anderen Ansatz zu sehen: RWA brauchen nicht nur einen Ort zur Ausgabe von Token, sondern eine Schicht, die den gesamten Transaktionslebenszyklus verarbeitet; dennoch muss ich eine Frage offenlassen: Eine passende Architektur bedeutet noch nicht automatisch tatsächliche Adoption.
Baut Dusk also بالفعل eine Settlement-Infrastruktur auf, oder nur das Fundament dafür?
#dusk $DUSK @Dusk $BTC
1
271
Übersetzung ansehen
Nếu bạn mới dùng Binance P2P có một thói quen tôi nghĩ nên tập ngay từ những giao dịch đầu tiên theo góc nhìn của tôi đó là đừng chọn người bán chỉ vì họ có giá tốt.
Tôi từng nghĩ chênh lệch vài đồng cũng chẳng đáng bao nhiêu nên thường nhìn giá trước rồi mới xem những thông tin còn lại nhưng sau nhiều giao dịch và khi đọc kỹ cách Binance hiển thị dữ liệu của từng quảng cáo thì tôi bắt đầu thấy thứ đáng kiểm tra không chỉ là mức giá.
Tôi thử xây cho mình một quy trình đơn giản trước mỗi lệnh mà bạn có thể tham khảo.
Đầu tiên là tôi xem số lượng giao dịch và tỷ lệ hoàn tất. Sau đó đọc feedback đặc biệt nếu có những phản hồi tiêu cực lặp lại.
Tiếp theo tôi kiểm tra giới hạn lệnh và phương thức thanh toán có thực sự phù hợp không.
Quan trọng hơn tôi đối chiếu thông tin thanh toán và không tự ý chuyển cuộc trò chuyện sang Telegram hay nền tảng khác.
Tuy nhiên có một điều tôi thấy là những dữ liệu này không thể biến một đối tác thành “an toàn tuyệt đối” mà chúng chỉ giúp mình có thêm cơ sở để đánh giá trước khi giao dịch.
Với giao dịch P2P theo tôi có lẽ điều quan trọng nhất không phải tìm được người bán rẻ nhất mà là hình thành thói quen kiểm tra trước khi bấm xác nhận.
Tôi không biết những kinh nghiệm này có giúp được mọi người không nhưng ít nhất đó là những gì tôi rút ra sau khi tự kiểm chứng.
#binancep2pantoan @Binance_Vietnam $BTC
Nếu bạn mới dùng Binance P2P có một thói quen tôi nghĩ nên tập ngay từ những giao dịch đầu tiên theo góc nhìn của tôi đó là đừng chọn người bán chỉ vì họ có giá tốt.
Tôi từng nghĩ chênh lệch vài đồng cũng chẳng đáng bao nhiêu nên thường nhìn giá trước rồi mới xem những thông tin còn lại nhưng sau nhiều giao dịch và khi đọc kỹ cách Binance hiển thị dữ liệu của từng quảng cáo thì tôi bắt đầu thấy thứ đáng kiểm tra không chỉ là mức giá.
Tôi thử xây cho mình một quy trình đơn giản trước mỗi lệnh mà bạn có thể tham khảo.
Đầu tiên là tôi xem số lượng giao dịch và tỷ lệ hoàn tất. Sau đó đọc feedback đặc biệt nếu có những phản hồi tiêu cực lặp lại.
Tiếp theo tôi kiểm tra giới hạn lệnh và phương thức thanh toán có thực sự phù hợp không.
Quan trọng hơn tôi đối chiếu thông tin thanh toán và không tự ý chuyển cuộc trò chuyện sang Telegram hay nền tảng khác.
Tuy nhiên có một điều tôi thấy là những dữ liệu này không thể biến một đối tác thành “an toàn tuyệt đối” mà chúng chỉ giúp mình có thêm cơ sở để đánh giá trước khi giao dịch.
Với giao dịch P2P theo tôi có lẽ điều quan trọng nhất không phải tìm được người bán rẻ nhất mà là hình thành thói quen kiểm tra trước khi bấm xác nhận.
Tôi không biết những kinh nghiệm này có giúp được mọi người không nhưng ít nhất đó là những gì tôi rút ra sau khi tự kiểm chứng.
#binancep2pantoan @Binance Vietnam $BTC
Tôi từng nghĩ chênh lệch vài đồng cũng chẳng đáng bao nhiêu nên thường nhìn giá trước rồi mới xem những thông tin còn lại nhưng sau nhiều giao dịch và khi đọc kỹ cách Binance hiển thị dữ liệu của từng quảng cáo thì tôi bắt đầu thấy thứ đáng kiểm tra không chỉ là mức giá.
Tôi thử xây cho mình một quy trình đơn giản trước mỗi lệnh mà bạn có thể tham khảo.
Đầu tiên là tôi xem số lượng giao dịch và tỷ lệ hoàn tất. Sau đó đọc feedback đặc biệt nếu có những phản hồi tiêu cực lặp lại.
Tiếp theo tôi kiểm tra giới hạn lệnh và phương thức thanh toán có thực sự phù hợp không.
Quan trọng hơn tôi đối chiếu thông tin thanh toán và không tự ý chuyển cuộc trò chuyện sang Telegram hay nền tảng khác.
Tuy nhiên có một điều tôi thấy là những dữ liệu này không thể biến một đối tác thành “an toàn tuyệt đối” mà chúng chỉ giúp mình có thêm cơ sở để đánh giá trước khi giao dịch.
Với giao dịch P2P theo tôi có lẽ điều quan trọng nhất không phải tìm được người bán rẻ nhất mà là hình thành thói quen kiểm tra trước khi bấm xác nhận.
Tôi không biết những kinh nghiệm này có giúp được mọi người không nhưng ít nhất đó là những gì tôi rút ra sau khi tự kiểm chứng.
#binancep2pantoan @Binance Vietnam $BTC
1
208
Übersetzung ansehen
Có một chi tiết khiến tôi phải đọc lại phần consensus của Dusk vài lần. Tôi ban đầu nghĩ Succinct Attestation chỉ là một cách gọi khác cho PoS nhưng flow bên trong có vài điểm đáng chú ý.
Theo tài liệu hiện tại, DuskDS sử dụng Succinct Attestation (SA) được Dusk mô tả rõ là một permissionless, committee based Proof of Stake consensus protocol. Provisioner muốn tham gia consensus phải stake tối thiểu 1.000 DUSK.
Tôi đi tiếp vào quy trình. Một round không đơn giản là các validator cùng bỏ phiếu cho block, nó được chia thành ba bước: Proposal, Validation và Ratification. Một provisioner đề xuất block, một committee kiểm tra sau đó committee khác xác nhận kết quả và hoàn tất block. Khi ratification hoàn tất, Dusk đạt deterministic finality.
Đến đây tôi phải sửa lại cách hiểu ban đầu.
SA không phải “một consensus khác hoàn toàn PoS”. Nền tảng kinh tế vẫn là staking, điểm Dusk tự thiết kế lại nằm ở cách chọn committee, phân tách các bước xác nhận và cách đưa block đến finality.
Khoan, điều này cũng chưa đủ để nói SA tốt hơn PoW hay PoS truyền thống.
PoW dựa vào cạnh tranh tính toán còn SA không cần cơ chế đó. Nhưng nói Dusk “thay thế PoS bằng một thứ hoàn toàn mới” thì không chính xác.
Điều tôi thấy đáng nghiên cứu hơn là: khi finality được thiết kế theo hướng deterministic, nó thay đổi trải nghiệm settlement cho các ứng dụng tài chính đến mức nào?
#dusk $DUSK @Dusk_Foundation $BTC
Có một chi tiết khiến tôi phải đọc lại phần consensus của Dusk vài lần. Tôi ban đầu nghĩ Succinct Attestation chỉ là một cách gọi khác cho PoS nhưng flow bên trong có vài điểm đáng chú ý.
Theo tài liệu hiện tại, DuskDS sử dụng Succinct Attestation (SA) được Dusk mô tả rõ là một permissionless, committee based Proof of Stake consensus protocol. Provisioner muốn tham gia consensus phải stake tối thiểu 1.000 DUSK.
Tôi đi tiếp vào quy trình. Một round không đơn giản là các validator cùng bỏ phiếu cho block, nó được chia thành ba bước: Proposal, Validation và Ratification. Một provisioner đề xuất block, một committee kiểm tra sau đó committee khác xác nhận kết quả và hoàn tất block. Khi ratification hoàn tất, Dusk đạt deterministic finality.
Đến đây tôi phải sửa lại cách hiểu ban đầu.
SA không phải “một consensus khác hoàn toàn PoS”. Nền tảng kinh tế vẫn là staking, điểm Dusk tự thiết kế lại nằm ở cách chọn committee, phân tách các bước xác nhận và cách đưa block đến finality.
Khoan, điều này cũng chưa đủ để nói SA tốt hơn PoW hay PoS truyền thống.
PoW dựa vào cạnh tranh tính toán còn SA không cần cơ chế đó. Nhưng nói Dusk “thay thế PoS bằng một thứ hoàn toàn mới” thì không chính xác.
Điều tôi thấy đáng nghiên cứu hơn là: khi finality được thiết kế theo hướng deterministic, nó thay đổi trải nghiệm settlement cho các ứng dụng tài chính đến mức nào?
#dusk $DUSK @Dusk $BTC
Theo tài liệu hiện tại, DuskDS sử dụng Succinct Attestation (SA) được Dusk mô tả rõ là một permissionless, committee based Proof of Stake consensus protocol. Provisioner muốn tham gia consensus phải stake tối thiểu 1.000 DUSK.
Tôi đi tiếp vào quy trình. Một round không đơn giản là các validator cùng bỏ phiếu cho block, nó được chia thành ba bước: Proposal, Validation và Ratification. Một provisioner đề xuất block, một committee kiểm tra sau đó committee khác xác nhận kết quả và hoàn tất block. Khi ratification hoàn tất, Dusk đạt deterministic finality.
Đến đây tôi phải sửa lại cách hiểu ban đầu.
SA không phải “một consensus khác hoàn toàn PoS”. Nền tảng kinh tế vẫn là staking, điểm Dusk tự thiết kế lại nằm ở cách chọn committee, phân tách các bước xác nhận và cách đưa block đến finality.
Khoan, điều này cũng chưa đủ để nói SA tốt hơn PoW hay PoS truyền thống.
PoW dựa vào cạnh tranh tính toán còn SA không cần cơ chế đó. Nhưng nói Dusk “thay thế PoS bằng một thứ hoàn toàn mới” thì không chính xác.
Điều tôi thấy đáng nghiên cứu hơn là: khi finality được thiết kế theo hướng deterministic, nó thay đổi trải nghiệm settlement cho các ứng dụng tài chính đến mức nào?
#dusk $DUSK @Dusk $BTC
220
Verifiziert
Übersetzung ansehen
Có gì đó khiến tôi dừng lại khi đọc về Dusk Network. Ban đầu, tôi nghĩ đây chỉ là một blockchain tập trung vào privacy và token hóa tài sản nhưng khi đối chiếu docs mới, tôi thấy cách Dusk định vị mình rộng hơn khá nhiều.
Dusk mô tả mình là hạ tầng cho regulated digital assets và onchain finance với trọng tâm là privacy, access control và deterministic settlement. Đây không chỉ là một câu chuyện về token.
Tôi bắt đầu nhìn vào kiến trúc. DuskDS đảm nhiệm consensus, finality và data availability; DuskVM chạy smart contract Rust/WASM trực tiếp trên L1; còn DuskEVM cung cấp môi trường EVM compatible, sử dụng DuskDS cho settlement.
Sau đó tôi đọc sâu hơn về regulated assets. Docs đề cập đến eligibility, wallet binding, transfer restrictions, disclosure, reporting và settlement coordination. Privacy cũng được chia thành hai hướng: Moonlight cho giao dịch công khai và Phoenix cho shielded transfers.
Lúc này tôi mới hiểu vì sao Dusk không chỉ nói về “đưa tài sản lên blockchain”. Họ đang cố đưa cả những ràng buộc của thị trường tài chính vào workflow onchain.
Nhưng khoan, kiến trúc được thiết kế cho regulated finance chưa đồng nghĩa adoption đã được chứng minh.
Có lẽ câu hỏi đáng theo dõi hơn là: liệu những primitive này có thực sự trở thành hạ tầng được các thị trường tài chính sử dụng hay không?
#dusk $DUSK @Dusk_Foundation $BTC
Có gì đó khiến tôi dừng lại khi đọc về Dusk Network. Ban đầu, tôi nghĩ đây chỉ là một blockchain tập trung vào privacy và token hóa tài sản nhưng khi đối chiếu docs mới, tôi thấy cách Dusk định vị mình rộng hơn khá nhiều.
Dusk mô tả mình là hạ tầng cho regulated digital assets và onchain finance với trọng tâm là privacy, access control và deterministic settlement. Đây không chỉ là một câu chuyện về token.
Tôi bắt đầu nhìn vào kiến trúc. DuskDS đảm nhiệm consensus, finality và data availability; DuskVM chạy smart contract Rust/WASM trực tiếp trên L1; còn DuskEVM cung cấp môi trường EVM compatible, sử dụng DuskDS cho settlement.
Sau đó tôi đọc sâu hơn về regulated assets. Docs đề cập đến eligibility, wallet binding, transfer restrictions, disclosure, reporting và settlement coordination. Privacy cũng được chia thành hai hướng: Moonlight cho giao dịch công khai và Phoenix cho shielded transfers.
Lúc này tôi mới hiểu vì sao Dusk không chỉ nói về “đưa tài sản lên blockchain”. Họ đang cố đưa cả những ràng buộc của thị trường tài chính vào workflow onchain.
Nhưng khoan, kiến trúc được thiết kế cho regulated finance chưa đồng nghĩa adoption đã được chứng minh.
Có lẽ câu hỏi đáng theo dõi hơn là: liệu những primitive này có thực sự trở thành hạ tầng được các thị trường tài chính sử dụng hay không?
#dusk $DUSK @Dusk $BTC
Dusk mô tả mình là hạ tầng cho regulated digital assets và onchain finance với trọng tâm là privacy, access control và deterministic settlement. Đây không chỉ là một câu chuyện về token.
Tôi bắt đầu nhìn vào kiến trúc. DuskDS đảm nhiệm consensus, finality và data availability; DuskVM chạy smart contract Rust/WASM trực tiếp trên L1; còn DuskEVM cung cấp môi trường EVM compatible, sử dụng DuskDS cho settlement.
Sau đó tôi đọc sâu hơn về regulated assets. Docs đề cập đến eligibility, wallet binding, transfer restrictions, disclosure, reporting và settlement coordination. Privacy cũng được chia thành hai hướng: Moonlight cho giao dịch công khai và Phoenix cho shielded transfers.
Lúc này tôi mới hiểu vì sao Dusk không chỉ nói về “đưa tài sản lên blockchain”. Họ đang cố đưa cả những ràng buộc của thị trường tài chính vào workflow onchain.
Nhưng khoan, kiến trúc được thiết kế cho regulated finance chưa đồng nghĩa adoption đã được chứng minh.
Có lẽ câu hỏi đáng theo dõi hơn là: liệu những primitive này có thực sự trở thành hạ tầng được các thị trường tài chính sử dụng hay không?
#dusk $DUSK @Dusk $BTC
1
1
91
Übersetzung ansehen
Thoạt nhìn, tôi từng nghĩ Binance P2P chỉ bổ sung thêm vài lớp bảo vệ cho giao dịch ngang hàng. Escrow, xác minh hay Appeal đều là những khái niệm khá quen thuộc.
Nhưng càng đọc kỹ, tôi càng thấy vấn đề thú vị hơn nằm ở chuyện gì xảy ra khi hai bên không còn thống nhất về giao dịch.
Ban đầu tôi cho rằng Chat và Appeal đơn giản là công cụ hỗ trợ khi có sự cố sau đó tôi nhận ra giá trị của chúng nằm ở việc giúp các bên cung cấp thông tin và bằng chứng để Binance xem xét khi tranh chấp phát sinh.
Quá trình khiếu nại có thể ghi nhận các bước xử lý, ghi chú và bằng chứng liên quan, điều này khiến tôi nhìn Appeal khác đi: không phải một cơ chế đảm bảo kết quả mà là một quy trình để xem xét sự việc dựa trên thông tin được cung cấp.
Điều khiến tôi bận tâm lại nằm ở hành vi của người dùng. Binance cũng khuyến nghị không dựa vào ảnh chụp hay SMS để xác nhận thanh toán và nên giữ lại chứng từ khi cần Appeal.
Đến lúc đó tôi mới hiểu, điểm đáng chú ý không chỉ là công nghệ. Nó nằm ở cách hệ thống duy trì một quy trình để các bên có thể đưa ra bằng chứng khi bất đồng xảy ra.
Càng nghĩ, tôi càng thấy đây giống một mô hình coordination hơn là một tính năng và có lẽ giá trị của infrastructure chỉ thực sự lộ ra khi giao dịch không còn đơn giản.
#binancep2pantoan @Binance_Vietnam $BTC
Thoạt nhìn, tôi từng nghĩ Binance P2P chỉ bổ sung thêm vài lớp bảo vệ cho giao dịch ngang hàng. Escrow, xác minh hay Appeal đều là những khái niệm khá quen thuộc.
Nhưng càng đọc kỹ, tôi càng thấy vấn đề thú vị hơn nằm ở chuyện gì xảy ra khi hai bên không còn thống nhất về giao dịch.
Ban đầu tôi cho rằng Chat và Appeal đơn giản là công cụ hỗ trợ khi có sự cố sau đó tôi nhận ra giá trị của chúng nằm ở việc giúp các bên cung cấp thông tin và bằng chứng để Binance xem xét khi tranh chấp phát sinh.
Quá trình khiếu nại có thể ghi nhận các bước xử lý, ghi chú và bằng chứng liên quan, điều này khiến tôi nhìn Appeal khác đi: không phải một cơ chế đảm bảo kết quả mà là một quy trình để xem xét sự việc dựa trên thông tin được cung cấp.
Điều khiến tôi bận tâm lại nằm ở hành vi của người dùng. Binance cũng khuyến nghị không dựa vào ảnh chụp hay SMS để xác nhận thanh toán và nên giữ lại chứng từ khi cần Appeal.
Đến lúc đó tôi mới hiểu, điểm đáng chú ý không chỉ là công nghệ. Nó nằm ở cách hệ thống duy trì một quy trình để các bên có thể đưa ra bằng chứng khi bất đồng xảy ra.
Càng nghĩ, tôi càng thấy đây giống một mô hình coordination hơn là một tính năng và có lẽ giá trị của infrastructure chỉ thực sự lộ ra khi giao dịch không còn đơn giản.
#binancep2pantoan @Binance Vietnam $BTC
Nhưng càng đọc kỹ, tôi càng thấy vấn đề thú vị hơn nằm ở chuyện gì xảy ra khi hai bên không còn thống nhất về giao dịch.
Ban đầu tôi cho rằng Chat và Appeal đơn giản là công cụ hỗ trợ khi có sự cố sau đó tôi nhận ra giá trị của chúng nằm ở việc giúp các bên cung cấp thông tin và bằng chứng để Binance xem xét khi tranh chấp phát sinh.
Quá trình khiếu nại có thể ghi nhận các bước xử lý, ghi chú và bằng chứng liên quan, điều này khiến tôi nhìn Appeal khác đi: không phải một cơ chế đảm bảo kết quả mà là một quy trình để xem xét sự việc dựa trên thông tin được cung cấp.
Điều khiến tôi bận tâm lại nằm ở hành vi của người dùng. Binance cũng khuyến nghị không dựa vào ảnh chụp hay SMS để xác nhận thanh toán và nên giữ lại chứng từ khi cần Appeal.
Đến lúc đó tôi mới hiểu, điểm đáng chú ý không chỉ là công nghệ. Nó nằm ở cách hệ thống duy trì một quy trình để các bên có thể đưa ra bằng chứng khi bất đồng xảy ra.
Càng nghĩ, tôi càng thấy đây giống một mô hình coordination hơn là một tính năng và có lẽ giá trị của infrastructure chỉ thực sự lộ ra khi giao dịch không còn đơn giản.
#binancep2pantoan @Binance Vietnam $BTC
1
210
Übersetzung ansehen
Có một chỗ khiến tôi phải đọc lại khi tìm hiểu Dusk Network. Tôi từng nghĩ tokenization khá đơn giản đó là: lấy một tài sản, tạo token đại diện cho nó rồi đưa token lên blockchain.
Nhưng tài liệu của Dusk định nghĩa rõ hơn. Tokenization là việc phát hành token đại diện cho một tài sản hoặc quyền đối với tài sản đó. Vấn đề là với tài sản được quản lý, custody, registry và settlement vẫn có thể nằm ngoài ledger.
Tôi bắt đầu nhìn vào phần còn lại của lifecycle: issuance, eligibility, transfer restrictions, disclosure, trading và settlement. Đây cũng là những workflow mà Dusk đưa vào thiết kế market infrastructure.
DuskDS đảm nhiệm settlement, finality và data availability. Citadel cung cấp identity và selective disclosure. Dusk Trade nằm ở application layer, xử lý các workflow như onboarding, trading và phối hợp asset-payment settlement.
Hóa ra điểm tôi bỏ sót ban đầu không phải bản thân token mà là những thứ xảy ra trước và sau một lần transfer.
Khoan, điều này cũng chưa có nghĩa mọi thứ đều tự động được đưa onchain, chính tài liệu Dusk nói kiến trúc cụ thể còn phụ thuộc vào sản phẩm và yêu cầu pháp lý.
Vì vậy cách tôi nhìn Dusk thay đổi một chút: tokenization ở đây không chỉ là tạo representation mà là xây dựng cả workflow quanh tài sản.
Vậy cuối cùng, giá trị nằm ở token hay ở hạ tầng khiến token đó thực sự có thể vận hành?
#dusk $DUSK @Dusk_Foundation $BTC
Có một chỗ khiến tôi phải đọc lại khi tìm hiểu Dusk Network. Tôi từng nghĩ tokenization khá đơn giản đó là: lấy một tài sản, tạo token đại diện cho nó rồi đưa token lên blockchain.
Nhưng tài liệu của Dusk định nghĩa rõ hơn. Tokenization là việc phát hành token đại diện cho một tài sản hoặc quyền đối với tài sản đó. Vấn đề là với tài sản được quản lý, custody, registry và settlement vẫn có thể nằm ngoài ledger.
Tôi bắt đầu nhìn vào phần còn lại của lifecycle: issuance, eligibility, transfer restrictions, disclosure, trading và settlement. Đây cũng là những workflow mà Dusk đưa vào thiết kế market infrastructure.
DuskDS đảm nhiệm settlement, finality và data availability. Citadel cung cấp identity và selective disclosure. Dusk Trade nằm ở application layer, xử lý các workflow như onboarding, trading và phối hợp asset-payment settlement.
Hóa ra điểm tôi bỏ sót ban đầu không phải bản thân token mà là những thứ xảy ra trước và sau một lần transfer.
Khoan, điều này cũng chưa có nghĩa mọi thứ đều tự động được đưa onchain, chính tài liệu Dusk nói kiến trúc cụ thể còn phụ thuộc vào sản phẩm và yêu cầu pháp lý.
Vì vậy cách tôi nhìn Dusk thay đổi một chút: tokenization ở đây không chỉ là tạo representation mà là xây dựng cả workflow quanh tài sản.
Vậy cuối cùng, giá trị nằm ở token hay ở hạ tầng khiến token đó thực sự có thể vận hành?
#dusk $DUSK @Dusk $BTC
Nhưng tài liệu của Dusk định nghĩa rõ hơn. Tokenization là việc phát hành token đại diện cho một tài sản hoặc quyền đối với tài sản đó. Vấn đề là với tài sản được quản lý, custody, registry và settlement vẫn có thể nằm ngoài ledger.
Tôi bắt đầu nhìn vào phần còn lại của lifecycle: issuance, eligibility, transfer restrictions, disclosure, trading và settlement. Đây cũng là những workflow mà Dusk đưa vào thiết kế market infrastructure.
DuskDS đảm nhiệm settlement, finality và data availability. Citadel cung cấp identity và selective disclosure. Dusk Trade nằm ở application layer, xử lý các workflow như onboarding, trading và phối hợp asset-payment settlement.
Hóa ra điểm tôi bỏ sót ban đầu không phải bản thân token mà là những thứ xảy ra trước và sau một lần transfer.
Khoan, điều này cũng chưa có nghĩa mọi thứ đều tự động được đưa onchain, chính tài liệu Dusk nói kiến trúc cụ thể còn phụ thuộc vào sản phẩm và yêu cầu pháp lý.
Vì vậy cách tôi nhìn Dusk thay đổi một chút: tokenization ở đây không chỉ là tạo representation mà là xây dựng cả workflow quanh tài sản.
Vậy cuối cùng, giá trị nằm ở token hay ở hạ tầng khiến token đó thực sự có thể vận hành?
#dusk $DUSK @Dusk $BTC
2
2
82
Übersetzung ansehen
Có lần tôi đặt một lệnh P2P rồi thấy phương thức thanh toán không phù hợp nên định hủy. Tôi nghĩ đó chỉ là thao tác bình thường cho đến khi tự hỏi: nếu ai cũng có thể hủy tùy ý, Binance dựa vào đâu để đánh giá một merchant đáng tin cậy?
Trước đây tôi thường nhìn việc hủy lệnh khá đơn giản là nếu không muốn giao dịch nữa thì hủy nhưng khi kiểm tra tài liệu Binance P2P Merchant Guidelines, cách nhìn này bắt đầu có vấn đề.
Binance ghi rõ merchant không được “cancel orders arbitrarily”. Đồng thời, order completion rate trong 30 ngày là một trong những chỉ số được dùng để đánh giá merchant; tỷ lệ hoàn thành thấp có thể dẫn đến việc bị loại khỏi chương trình merchant.
Tôi đọc tiếp phần trading principles để xem Binance có cấm tuyệt đối việc hủy hay không. Không phải, tài liệu vẫn nêu những trường hợp merchant có thể hủy, chẳng hạn khi thông tin tài khoản thanh toán của đối tác không đáp ứng yêu cầu hoặc người dùng từ chối một số bước xác minh bổ sung.
Đến đây tôi phải sửa lại cách hiểu ban đầu.
Vấn đề không nằm ở việc “hủy lệnh là sai”. Vấn đề nằm ở chữ “tùy tiện”. Binance đang phân biệt giữa một lý do hợp lệ để chấm dứt giao dịch và việc hủy đơn không có cơ sở.
Khoan, điều này cũng chưa đủ để nói rằng một lần hủy chắc chắn sẽ bị phạt. Tài liệu nói về các tiêu chí đánh giá và những trường hợp vi phạm, chứ không đơn giản là cứ bấm hủy một lần là bị xử lý.
Có lẽ điều đáng chú ý hơn là: trong P2P, một thao tác tưởng như rất nhỏ lại được đặt trong cả một hệ thống đánh giá về mức độ hoàn thành và độ tin cậy của merchant.
#binancep2pantoan @Binance_Vietnam $BTC
Có lần tôi đặt một lệnh P2P rồi thấy phương thức thanh toán không phù hợp nên định hủy. Tôi nghĩ đó chỉ là thao tác bình thường cho đến khi tự hỏi: nếu ai cũng có thể hủy tùy ý, Binance dựa vào đâu để đánh giá một merchant đáng tin cậy?
Trước đây tôi thường nhìn việc hủy lệnh khá đơn giản là nếu không muốn giao dịch nữa thì hủy nhưng khi kiểm tra tài liệu Binance P2P Merchant Guidelines, cách nhìn này bắt đầu có vấn đề.
Binance ghi rõ merchant không được “cancel orders arbitrarily”. Đồng thời, order completion rate trong 30 ngày là một trong những chỉ số được dùng để đánh giá merchant; tỷ lệ hoàn thành thấp có thể dẫn đến việc bị loại khỏi chương trình merchant.
Tôi đọc tiếp phần trading principles để xem Binance có cấm tuyệt đối việc hủy hay không. Không phải, tài liệu vẫn nêu những trường hợp merchant có thể hủy, chẳng hạn khi thông tin tài khoản thanh toán của đối tác không đáp ứng yêu cầu hoặc người dùng từ chối một số bước xác minh bổ sung.
Đến đây tôi phải sửa lại cách hiểu ban đầu.
Vấn đề không nằm ở việc “hủy lệnh là sai”. Vấn đề nằm ở chữ “tùy tiện”. Binance đang phân biệt giữa một lý do hợp lệ để chấm dứt giao dịch và việc hủy đơn không có cơ sở.
Khoan, điều này cũng chưa đủ để nói rằng một lần hủy chắc chắn sẽ bị phạt. Tài liệu nói về các tiêu chí đánh giá và những trường hợp vi phạm, chứ không đơn giản là cứ bấm hủy một lần là bị xử lý.
Có lẽ điều đáng chú ý hơn là: trong P2P, một thao tác tưởng như rất nhỏ lại được đặt trong cả một hệ thống đánh giá về mức độ hoàn thành và độ tin cậy của merchant.
#binancep2pantoan @Binance Vietnam $BTC
Trước đây tôi thường nhìn việc hủy lệnh khá đơn giản là nếu không muốn giao dịch nữa thì hủy nhưng khi kiểm tra tài liệu Binance P2P Merchant Guidelines, cách nhìn này bắt đầu có vấn đề.
Binance ghi rõ merchant không được “cancel orders arbitrarily”. Đồng thời, order completion rate trong 30 ngày là một trong những chỉ số được dùng để đánh giá merchant; tỷ lệ hoàn thành thấp có thể dẫn đến việc bị loại khỏi chương trình merchant.
Tôi đọc tiếp phần trading principles để xem Binance có cấm tuyệt đối việc hủy hay không. Không phải, tài liệu vẫn nêu những trường hợp merchant có thể hủy, chẳng hạn khi thông tin tài khoản thanh toán của đối tác không đáp ứng yêu cầu hoặc người dùng từ chối một số bước xác minh bổ sung.
Đến đây tôi phải sửa lại cách hiểu ban đầu.
Vấn đề không nằm ở việc “hủy lệnh là sai”. Vấn đề nằm ở chữ “tùy tiện”. Binance đang phân biệt giữa một lý do hợp lệ để chấm dứt giao dịch và việc hủy đơn không có cơ sở.
Khoan, điều này cũng chưa đủ để nói rằng một lần hủy chắc chắn sẽ bị phạt. Tài liệu nói về các tiêu chí đánh giá và những trường hợp vi phạm, chứ không đơn giản là cứ bấm hủy một lần là bị xử lý.
Có lẽ điều đáng chú ý hơn là: trong P2P, một thao tác tưởng như rất nhỏ lại được đặt trong cả một hệ thống đánh giá về mức độ hoàn thành và độ tin cậy của merchant.
#binancep2pantoan @Binance Vietnam $BTC
1
186
Übersetzung ansehen
Hôm nay tôi đã giành cả buổi chiều để nghiền ngẫm Dusk Network để tham gia chương trình Creatorpad của dự án trên Binance.
Có một chi tiết khiến tôi phải đọc lại phần privacy của Dusk Network. “Selective Disclosure” nghe khá đơn giản: giữ dữ liệu riêng tư nhưng khi cần thì tiết lộ. Nhưng khi đi xuống docs, cách Dusk phân tách các thành phần lại khác với cách tôi hình dung ban đầu.
Dusk hiện mô tả privacy theo ba hướng: tài khoản public với Moonlight, giao dịch shielded với Phoenix và selective disclosure khi một bên được ủy quyền cần bằng chứng.
Tôi đào sâu vào Citadel vì docs xác định đây là identity và access layer cho selective disclosure. Citadel dùng zero knowledge proofs để người dùng có thể chứng minh mình sở hữu một license hợp lệ mà không cần công khai toàn bộ thông tin định danh.
Điểm đáng chú ý nằm ở chỗ này: ví dụ trong docs không nói “tiết lộ toàn bộ danh tính”. Người dùng tạo proof sau đó service provider kiểm tra quyền hợp lệ thông qua quy trình của Citadel.
Khoan, như vậy vẫn chưa có nghĩa mọi dữ liệu trên Dusk đều tự động được tiết lộ có chọn lọc. Docs chỉ mô tả các primitive và pattern để ứng dụng xây workflow phù hợp.
Có lẽ đây mới là điểm tôi cần giữ lại: Selective Disclosure của Dusk không phải “privacy nhưng có nút bật công khai” mà là cách tách quyền chứng minh một thông tin khỏi việc công khai toàn bộ thông tin.
Vậy câu hỏi tiếp theo mới thú vị: những primitive này được triển khai đến đâu trong các ứng dụng thực tế?
#dusk $DUSK @Dusk_Foundation $BTC
Hôm nay tôi đã giành cả buổi chiều để nghiền ngẫm Dusk Network để tham gia chương trình Creatorpad của dự án trên Binance.
Có một chi tiết khiến tôi phải đọc lại phần privacy của Dusk Network. “Selective Disclosure” nghe khá đơn giản: giữ dữ liệu riêng tư nhưng khi cần thì tiết lộ. Nhưng khi đi xuống docs, cách Dusk phân tách các thành phần lại khác với cách tôi hình dung ban đầu.
Dusk hiện mô tả privacy theo ba hướng: tài khoản public với Moonlight, giao dịch shielded với Phoenix và selective disclosure khi một bên được ủy quyền cần bằng chứng.
Tôi đào sâu vào Citadel vì docs xác định đây là identity và access layer cho selective disclosure. Citadel dùng zero knowledge proofs để người dùng có thể chứng minh mình sở hữu một license hợp lệ mà không cần công khai toàn bộ thông tin định danh.
Điểm đáng chú ý nằm ở chỗ này: ví dụ trong docs không nói “tiết lộ toàn bộ danh tính”. Người dùng tạo proof sau đó service provider kiểm tra quyền hợp lệ thông qua quy trình của Citadel.
Khoan, như vậy vẫn chưa có nghĩa mọi dữ liệu trên Dusk đều tự động được tiết lộ có chọn lọc. Docs chỉ mô tả các primitive và pattern để ứng dụng xây workflow phù hợp.
Có lẽ đây mới là điểm tôi cần giữ lại: Selective Disclosure của Dusk không phải “privacy nhưng có nút bật công khai” mà là cách tách quyền chứng minh một thông tin khỏi việc công khai toàn bộ thông tin.
Vậy câu hỏi tiếp theo mới thú vị: những primitive này được triển khai đến đâu trong các ứng dụng thực tế?
#dusk $DUSK @Dusk $BTC
Có một chi tiết khiến tôi phải đọc lại phần privacy của Dusk Network. “Selective Disclosure” nghe khá đơn giản: giữ dữ liệu riêng tư nhưng khi cần thì tiết lộ. Nhưng khi đi xuống docs, cách Dusk phân tách các thành phần lại khác với cách tôi hình dung ban đầu.
Dusk hiện mô tả privacy theo ba hướng: tài khoản public với Moonlight, giao dịch shielded với Phoenix và selective disclosure khi một bên được ủy quyền cần bằng chứng.
Tôi đào sâu vào Citadel vì docs xác định đây là identity và access layer cho selective disclosure. Citadel dùng zero knowledge proofs để người dùng có thể chứng minh mình sở hữu một license hợp lệ mà không cần công khai toàn bộ thông tin định danh.
Điểm đáng chú ý nằm ở chỗ này: ví dụ trong docs không nói “tiết lộ toàn bộ danh tính”. Người dùng tạo proof sau đó service provider kiểm tra quyền hợp lệ thông qua quy trình của Citadel.
Khoan, như vậy vẫn chưa có nghĩa mọi dữ liệu trên Dusk đều tự động được tiết lộ có chọn lọc. Docs chỉ mô tả các primitive và pattern để ứng dụng xây workflow phù hợp.
Có lẽ đây mới là điểm tôi cần giữ lại: Selective Disclosure của Dusk không phải “privacy nhưng có nút bật công khai” mà là cách tách quyền chứng minh một thông tin khỏi việc công khai toàn bộ thông tin.
Vậy câu hỏi tiếp theo mới thú vị: những primitive này được triển khai đến đâu trong các ứng dụng thực tế?
#dusk $DUSK @Dusk $BTC
2
2
238
Übersetzung ansehen
Có một tình huống khá đơn giản khiến tôi thay đổi cách nhìn về việc chọn đối tác trên Binance P2P.
Giả sử tôi cần mua 1.000 USDT và thấy hai quảng cáo có mức giá gần như tương đương. Người A đã hoàn thành khoảng 2.800 giao dịch, completion rate 99,6%. Người B dù có giá tốt hơn nhưng mới có 45 giao dịch và tỷ lệ hoàn thành 91%.
Nếu chỉ nhìn giá, tôi có thể chọn bất kỳ ai nhưng khi đọc hướng dẫn của Binance, tôi thấy nền tảng khuyến nghị kiểm tra completion rate, tổng số giao dịch đã hoàn thành và feedback của counterparty trước khi giao dịch.
Tôi bắt đầu nhìn hai quảng cáo khác đi.
2.800 giao dịch không chứng minh người A chắc chắn sẽ không có vấn đề nhưng nó cho tôi một lượng dữ liệu lịch sử lớn hơn để đánh giá. Ngược lại, 45 giao dịch và completion rate thấp hơn khiến tôi có ít cơ sở hơn để tin vào độ ổn định của đối tác.
Binance cũng hiển thị các dữ liệu như số giao dịch 30 ngày, completion rate 30 ngày và thời gian release trung bình.
Nhưng khoan, những con số này chỉ là tín hiệu chứ không phải bảo hiểm cho giao dịch tiếp theo.
Tôi sẽ không xem completion rate hay số lượng giao dịch như một tấm vé bảo đảm. Chúng chỉ giúp tôi có thêm cơ sở để lựa chọn còn phần kiểm tra giao dịch cụ thể vẫn nằm ở chính mình.
#binancep2pantoan @Binance_Vietnam $BTC
Có một tình huống khá đơn giản khiến tôi thay đổi cách nhìn về việc chọn đối tác trên Binance P2P.
Giả sử tôi cần mua 1.000 USDT và thấy hai quảng cáo có mức giá gần như tương đương. Người A đã hoàn thành khoảng 2.800 giao dịch, completion rate 99,6%. Người B dù có giá tốt hơn nhưng mới có 45 giao dịch và tỷ lệ hoàn thành 91%.
Nếu chỉ nhìn giá, tôi có thể chọn bất kỳ ai nhưng khi đọc hướng dẫn của Binance, tôi thấy nền tảng khuyến nghị kiểm tra completion rate, tổng số giao dịch đã hoàn thành và feedback của counterparty trước khi giao dịch.
Tôi bắt đầu nhìn hai quảng cáo khác đi.
2.800 giao dịch không chứng minh người A chắc chắn sẽ không có vấn đề nhưng nó cho tôi một lượng dữ liệu lịch sử lớn hơn để đánh giá. Ngược lại, 45 giao dịch và completion rate thấp hơn khiến tôi có ít cơ sở hơn để tin vào độ ổn định của đối tác.
Binance cũng hiển thị các dữ liệu như số giao dịch 30 ngày, completion rate 30 ngày và thời gian release trung bình.
Nhưng khoan, những con số này chỉ là tín hiệu chứ không phải bảo hiểm cho giao dịch tiếp theo.
Tôi sẽ không xem completion rate hay số lượng giao dịch như một tấm vé bảo đảm. Chúng chỉ giúp tôi có thêm cơ sở để lựa chọn còn phần kiểm tra giao dịch cụ thể vẫn nằm ở chính mình.
#binancep2pantoan @Binance Vietnam $BTC
Giả sử tôi cần mua 1.000 USDT và thấy hai quảng cáo có mức giá gần như tương đương. Người A đã hoàn thành khoảng 2.800 giao dịch, completion rate 99,6%. Người B dù có giá tốt hơn nhưng mới có 45 giao dịch và tỷ lệ hoàn thành 91%.
Nếu chỉ nhìn giá, tôi có thể chọn bất kỳ ai nhưng khi đọc hướng dẫn của Binance, tôi thấy nền tảng khuyến nghị kiểm tra completion rate, tổng số giao dịch đã hoàn thành và feedback của counterparty trước khi giao dịch.
Tôi bắt đầu nhìn hai quảng cáo khác đi.
2.800 giao dịch không chứng minh người A chắc chắn sẽ không có vấn đề nhưng nó cho tôi một lượng dữ liệu lịch sử lớn hơn để đánh giá. Ngược lại, 45 giao dịch và completion rate thấp hơn khiến tôi có ít cơ sở hơn để tin vào độ ổn định của đối tác.
Binance cũng hiển thị các dữ liệu như số giao dịch 30 ngày, completion rate 30 ngày và thời gian release trung bình.
Nhưng khoan, những con số này chỉ là tín hiệu chứ không phải bảo hiểm cho giao dịch tiếp theo.
Tôi sẽ không xem completion rate hay số lượng giao dịch như một tấm vé bảo đảm. Chúng chỉ giúp tôi có thêm cơ sở để lựa chọn còn phần kiểm tra giao dịch cụ thể vẫn nằm ở chính mình.
#binancep2pantoan @Binance Vietnam $BTC
131
Übersetzung ansehen
Có một chi tiết khiến tôi phải đọc lại kiến trúc Dusk thêm một lần. Ban đầu tôi nghĩ DuskDS đơn giản là phần blockchain nằm phía dưới DuskEVM nhưng tài liệu kỹ thuật mô tả nó rộng hơn thế.
DuskDS được xác định là lớp settlement và data availability của Dusk L1, phụ trách consensus, finality và các transaction model native. DuskEVM là execution layer sử dụng DuskDS cho settlement và data availability. DuskVM thì thực thi contract trực tiếp trên Dusk L1.
Tôi đào sâu hơn vào cách settlement thực sự được xác nhận. DuskDS sử dụng Succinct Attestation, một cơ chế Proof-of-Stake dựa trên committee. Quy trình gồm proposal, validation rồi ratification, khi block được ratify, finality mang tính deterministic.
Sau đó tôi nhìn vào transaction model. Moonlight xử lý account công khai còn Phoenix dùng shielded notes và zero knowledge proofs. Hai mô hình khác nhau nhưng cuối cùng đều settle trên cùng chain.
Khoan, điều này chưa có nghĩa DuskDS tự mình xử lý toàn bộ logic ứng dụng. Execution vẫn thuộc về DuskVM hoặc DuskEVM nhưng chính chỗ này làm tôi thay đổi cách nhìn: Dusk đang tách khá rõ execution khỏi settlement.
Nếu vậy, câu hỏi đáng theo dõi không còn là DuskDS có phải settlement layer hay không mà là: kiến trúc tách settlement này sẽ tạo khác biệt thực tế thế nào khi các ứng dụng tài chính bắt đầu chạy ở quy mô lớn?
#dusk $DUSK @Dusk_Foundation
Có một chi tiết khiến tôi phải đọc lại kiến trúc Dusk thêm một lần. Ban đầu tôi nghĩ DuskDS đơn giản là phần blockchain nằm phía dưới DuskEVM nhưng tài liệu kỹ thuật mô tả nó rộng hơn thế.
DuskDS được xác định là lớp settlement và data availability của Dusk L1, phụ trách consensus, finality và các transaction model native. DuskEVM là execution layer sử dụng DuskDS cho settlement và data availability. DuskVM thì thực thi contract trực tiếp trên Dusk L1.
Tôi đào sâu hơn vào cách settlement thực sự được xác nhận. DuskDS sử dụng Succinct Attestation, một cơ chế Proof-of-Stake dựa trên committee. Quy trình gồm proposal, validation rồi ratification, khi block được ratify, finality mang tính deterministic.
Sau đó tôi nhìn vào transaction model. Moonlight xử lý account công khai còn Phoenix dùng shielded notes và zero knowledge proofs. Hai mô hình khác nhau nhưng cuối cùng đều settle trên cùng chain.
Khoan, điều này chưa có nghĩa DuskDS tự mình xử lý toàn bộ logic ứng dụng. Execution vẫn thuộc về DuskVM hoặc DuskEVM nhưng chính chỗ này làm tôi thay đổi cách nhìn: Dusk đang tách khá rõ execution khỏi settlement.
Nếu vậy, câu hỏi đáng theo dõi không còn là DuskDS có phải settlement layer hay không mà là: kiến trúc tách settlement này sẽ tạo khác biệt thực tế thế nào khi các ứng dụng tài chính bắt đầu chạy ở quy mô lớn?
#dusk $DUSK @Dusk
DuskDS được xác định là lớp settlement và data availability của Dusk L1, phụ trách consensus, finality và các transaction model native. DuskEVM là execution layer sử dụng DuskDS cho settlement và data availability. DuskVM thì thực thi contract trực tiếp trên Dusk L1.
Tôi đào sâu hơn vào cách settlement thực sự được xác nhận. DuskDS sử dụng Succinct Attestation, một cơ chế Proof-of-Stake dựa trên committee. Quy trình gồm proposal, validation rồi ratification, khi block được ratify, finality mang tính deterministic.
Sau đó tôi nhìn vào transaction model. Moonlight xử lý account công khai còn Phoenix dùng shielded notes và zero knowledge proofs. Hai mô hình khác nhau nhưng cuối cùng đều settle trên cùng chain.
Khoan, điều này chưa có nghĩa DuskDS tự mình xử lý toàn bộ logic ứng dụng. Execution vẫn thuộc về DuskVM hoặc DuskEVM nhưng chính chỗ này làm tôi thay đổi cách nhìn: Dusk đang tách khá rõ execution khỏi settlement.
Nếu vậy, câu hỏi đáng theo dõi không còn là DuskDS có phải settlement layer hay không mà là: kiến trúc tách settlement này sẽ tạo khác biệt thực tế thế nào khi các ứng dụng tài chính bắt đầu chạy ở quy mô lớn?
#dusk $DUSK @Dusk
1
3
69
Es gibt eine Situation, die ich denke, dass viele Neue sehr leicht beim Verkauf von USDT auf Binance P2P erleben können – die ich selbst auch schon einmal hatte.
Einmal habe ich einen Verkaufsauftrag über 350 USDT eingestellt. Der Käufer meldete, er habe das Geld überwiesen, und schrieb sofort: „Bitte prüf das kurz und gib dann frei, ich brauche dringend USDT.“
Kurz darauf schickte er mir ein Foto, das angeblich die erfolgreiche Banküberweisung zeigt. Ich öffnete das Bild und schaute mir den Betrag, die Zeit und den Namen des Empfängers an. Alles wirkte stimmig, aber als ich dann die Banking-App direkt auf meinem eigenen Smartphone öffnete, war das Geld immer noch nicht da.
Ich werde warten, bis das Geld tatsächlich auf dem Empfängerkonto erscheint, statt mich von der Dringlichkeit der anderen Person zum richtigen Zeitpunkt des Freigebens drängen zu lassen.
Möglicherweise ist der Käufer vollkommen ehrlich, oder die Banküberweisung ist einfach nur verzögert.
Ich möchte wissen, ob dieser Druck wirklich die Abläufe verändert.
Wenn ich die Unterlagen noch einmal lese, sehe ich, dass Binance empfiehlt, die Kommunikation innerhalb der Plattform zu halten, das Geld direkt im Empfängerkonto zu prüfen und nicht anhand von Screenshots, SMS oder Bestätigungen der anderen Partei freizugeben. Wenn es Probleme gibt, kann die Transaktion in die Appeal (Einspruchsprüfung) überführt werden und es können Belege bereitgestellt werden.
Moment, das heißt nicht, dass immer, wenn jemand Druck macht, es Betrug ist. Vielleicht wollen sie einfach, dass die Transaktion schnell abgeschlossen wird – aber genau diese Stelle macht mich aufmerksam: Das Escrow schützt zwar das Guthaben, ersetzt jedoch nicht die Verifizierung durch den Nutzer.
Wenn man es weiter betrachtet: P2P ist immer noch ein Prozess mit einem gewissen manuellen Anteil, daher ist menschlicher Druck immer vorhanden.
Deshalb lasse ich nicht zu, dass mich die Dringlichkeit der anderen Person die Transaktion entscheiden lässt. Ich gebe erst frei, wenn das Geld auf dem Konto angekommen ist. Vielleicht bin ich etwas vorsichtig, aber im P2P ist Vorsicht immer besser als auf etwas zu vertrauen, das man noch nicht bestätigt hat.
#binancep2pantoan @Binance_Vietnam $BTC
Es gibt eine Situation, die ich denke, dass viele Neue sehr leicht beim Verkauf von USDT auf Binance P2P erleben können – die ich selbst auch schon einmal hatte.
Einmal habe ich einen Verkaufsauftrag über 350 USDT eingestellt. Der Käufer meldete, er habe das Geld überwiesen, und schrieb sofort: „Bitte prüf das kurz und gib dann frei, ich brauche dringend USDT.“
Kurz darauf schickte er mir ein Foto, das angeblich die erfolgreiche Banküberweisung zeigt. Ich öffnete das Bild und schaute mir den Betrag, die Zeit und den Namen des Empfängers an. Alles wirkte stimmig, aber als ich dann die Banking-App direkt auf meinem eigenen Smartphone öffnete, war das Geld immer noch nicht da.
Ich werde warten, bis das Geld tatsächlich auf dem Empfängerkonto erscheint, statt mich von der Dringlichkeit der anderen Person zum richtigen Zeitpunkt des Freigebens drängen zu lassen.
Möglicherweise ist der Käufer vollkommen ehrlich, oder die Banküberweisung ist einfach nur verzögert.
Ich möchte wissen, ob dieser Druck wirklich die Abläufe verändert.
Wenn ich die Unterlagen noch einmal lese, sehe ich, dass Binance empfiehlt, die Kommunikation innerhalb der Plattform zu halten, das Geld direkt im Empfängerkonto zu prüfen und nicht anhand von Screenshots, SMS oder Bestätigungen der anderen Partei freizugeben. Wenn es Probleme gibt, kann die Transaktion in die Appeal (Einspruchsprüfung) überführt werden und es können Belege bereitgestellt werden.
Moment, das heißt nicht, dass immer, wenn jemand Druck macht, es Betrug ist. Vielleicht wollen sie einfach, dass die Transaktion schnell abgeschlossen wird – aber genau diese Stelle macht mich aufmerksam: Das Escrow schützt zwar das Guthaben, ersetzt jedoch nicht die Verifizierung durch den Nutzer.
Wenn man es weiter betrachtet: P2P ist immer noch ein Prozess mit einem gewissen manuellen Anteil, daher ist menschlicher Druck immer vorhanden.
Deshalb lasse ich nicht zu, dass mich die Dringlichkeit der anderen Person die Transaktion entscheiden lässt. Ich gebe erst frei, wenn das Geld auf dem Konto angekommen ist. Vielleicht bin ich etwas vorsichtig, aber im P2P ist Vorsicht immer besser als auf etwas zu vertrauen, das man noch nicht bestätigt hat.
#binancep2pantoan @Binance Vietnam $BTC
Einmal habe ich einen Verkaufsauftrag über 350 USDT eingestellt. Der Käufer meldete, er habe das Geld überwiesen, und schrieb sofort: „Bitte prüf das kurz und gib dann frei, ich brauche dringend USDT.“
Kurz darauf schickte er mir ein Foto, das angeblich die erfolgreiche Banküberweisung zeigt. Ich öffnete das Bild und schaute mir den Betrag, die Zeit und den Namen des Empfängers an. Alles wirkte stimmig, aber als ich dann die Banking-App direkt auf meinem eigenen Smartphone öffnete, war das Geld immer noch nicht da.
Ich werde warten, bis das Geld tatsächlich auf dem Empfängerkonto erscheint, statt mich von der Dringlichkeit der anderen Person zum richtigen Zeitpunkt des Freigebens drängen zu lassen.
Möglicherweise ist der Käufer vollkommen ehrlich, oder die Banküberweisung ist einfach nur verzögert.
Ich möchte wissen, ob dieser Druck wirklich die Abläufe verändert.
Wenn ich die Unterlagen noch einmal lese, sehe ich, dass Binance empfiehlt, die Kommunikation innerhalb der Plattform zu halten, das Geld direkt im Empfängerkonto zu prüfen und nicht anhand von Screenshots, SMS oder Bestätigungen der anderen Partei freizugeben. Wenn es Probleme gibt, kann die Transaktion in die Appeal (Einspruchsprüfung) überführt werden und es können Belege bereitgestellt werden.
Moment, das heißt nicht, dass immer, wenn jemand Druck macht, es Betrug ist. Vielleicht wollen sie einfach, dass die Transaktion schnell abgeschlossen wird – aber genau diese Stelle macht mich aufmerksam: Das Escrow schützt zwar das Guthaben, ersetzt jedoch nicht die Verifizierung durch den Nutzer.
Wenn man es weiter betrachtet: P2P ist immer noch ein Prozess mit einem gewissen manuellen Anteil, daher ist menschlicher Druck immer vorhanden.
Deshalb lasse ich nicht zu, dass mich die Dringlichkeit der anderen Person die Transaktion entscheiden lässt. Ich gebe erst frei, wenn das Geld auf dem Konto angekommen ist. Vielleicht bin ich etwas vorsichtig, aber im P2P ist Vorsicht immer besser als auf etwas zu vertrauen, das man noch nicht bestätigt hat.
#binancep2pantoan @Binance Vietnam $BTC
1
188
Übersetzung ansehen
Có một chi tiết khiến tôi dừng lại khi đọc về Dusk Network: họ không định nghĩa privacy đơn giản là che mọi dữ liệu mà đặt nó cạnh khả năng tiết lộ có chọn lọc.
Tôi đọc lại kiến trúc và thấy DuskDS hỗ trợ hai mô hình giao dịch khá khác nhau. Moonlight là public còn Phoenix sử dụng shielded notes và zero-knowledge proofs để không công khai số tiền, người gửi hay mối liên hệ giữa các note.
Điều tôi muốn kiểm tra là privacy này có thực sự liên quan đến yêu cầu của thị trường tài chính hay chỉ là một tính năng kỹ thuật.
Trong tài liệu về regulated assets, Dusk mô tả một tình huống khá thực tế: nhà đầu tư không cần để mọi participant nhìn thấy toàn bộ số dư hay giao dịch nhưng issuer, venue hoặc auditor vẫn có thể cần một phần thông tin cụ thể. Dusk gọi hướng này là selective disclosure.
Khoan, tôi không nên từ đó suy ra rằng các tổ chức tài chính đã sử dụng Dusk trên quy mô thực tế.
Nhưng tôi nhận ra điểm đáng chú ý nằm ở cách bài toán được đặt ra: privacy không nhất thiết đối lập với transparency. Một hệ thống có thể giữ dữ liệu riêng tư trong giao dịch đồng thời cho phép cung cấp bằng chứng hoặc thông tin cần thiết cho đúng bên.
Nếu vậy, câu hỏi tôi còn muốn kiểm tra tiếp là: với tài chính được quản lý, privacy thực sự có giá trị khi nào: lúc dữ liệu cần được bảo vệ hay lúc nó cần được tiết lộ đúng người?
#dusk $DUSK @Dusk_Foundation
Có một chi tiết khiến tôi dừng lại khi đọc về Dusk Network: họ không định nghĩa privacy đơn giản là che mọi dữ liệu mà đặt nó cạnh khả năng tiết lộ có chọn lọc.
Tôi đọc lại kiến trúc và thấy DuskDS hỗ trợ hai mô hình giao dịch khá khác nhau. Moonlight là public còn Phoenix sử dụng shielded notes và zero-knowledge proofs để không công khai số tiền, người gửi hay mối liên hệ giữa các note.
Điều tôi muốn kiểm tra là privacy này có thực sự liên quan đến yêu cầu của thị trường tài chính hay chỉ là một tính năng kỹ thuật.
Trong tài liệu về regulated assets, Dusk mô tả một tình huống khá thực tế: nhà đầu tư không cần để mọi participant nhìn thấy toàn bộ số dư hay giao dịch nhưng issuer, venue hoặc auditor vẫn có thể cần một phần thông tin cụ thể. Dusk gọi hướng này là selective disclosure.
Khoan, tôi không nên từ đó suy ra rằng các tổ chức tài chính đã sử dụng Dusk trên quy mô thực tế.
Nhưng tôi nhận ra điểm đáng chú ý nằm ở cách bài toán được đặt ra: privacy không nhất thiết đối lập với transparency. Một hệ thống có thể giữ dữ liệu riêng tư trong giao dịch đồng thời cho phép cung cấp bằng chứng hoặc thông tin cần thiết cho đúng bên.
Nếu vậy, câu hỏi tôi còn muốn kiểm tra tiếp là: với tài chính được quản lý, privacy thực sự có giá trị khi nào: lúc dữ liệu cần được bảo vệ hay lúc nó cần được tiết lộ đúng người?
#dusk $DUSK @Dusk
Tôi đọc lại kiến trúc và thấy DuskDS hỗ trợ hai mô hình giao dịch khá khác nhau. Moonlight là public còn Phoenix sử dụng shielded notes và zero-knowledge proofs để không công khai số tiền, người gửi hay mối liên hệ giữa các note.
Điều tôi muốn kiểm tra là privacy này có thực sự liên quan đến yêu cầu của thị trường tài chính hay chỉ là một tính năng kỹ thuật.
Trong tài liệu về regulated assets, Dusk mô tả một tình huống khá thực tế: nhà đầu tư không cần để mọi participant nhìn thấy toàn bộ số dư hay giao dịch nhưng issuer, venue hoặc auditor vẫn có thể cần một phần thông tin cụ thể. Dusk gọi hướng này là selective disclosure.
Khoan, tôi không nên từ đó suy ra rằng các tổ chức tài chính đã sử dụng Dusk trên quy mô thực tế.
Nhưng tôi nhận ra điểm đáng chú ý nằm ở cách bài toán được đặt ra: privacy không nhất thiết đối lập với transparency. Một hệ thống có thể giữ dữ liệu riêng tư trong giao dịch đồng thời cho phép cung cấp bằng chứng hoặc thông tin cần thiết cho đúng bên.
Nếu vậy, câu hỏi tôi còn muốn kiểm tra tiếp là: với tài chính được quản lý, privacy thực sự có giá trị khi nào: lúc dữ liệu cần được bảo vệ hay lúc nó cần được tiết lộ đúng người?
#dusk $DUSK @Dusk
4
2
97
Ich bin einmal auf eine Situation gestoßen, durch die ich die Binance-P2P-Anleitung noch einmal lesen musste: Als ich nach dem Gewinn eines Airdrops von Binance Alpha 200 USDT verkaufte, schickte mir der Käufer einen Screenshot, der angeblich die Überweisung bestätigte, und drängte mich, die Krypto freizugeben. Auf den ersten Blick wirkte alles recht normal, aber als ich das Konto für den Zahlungseingang direkt überprüfte, stellte ich fest, dass das Geld dort noch gar nicht angekommen war. Aus dieser Situation heraus achtete ich auf einen weiteren Punkt in der Binance-Anleitung: Verkäufer sollten die Krypto erst freigeben, nachdem sie selbst bestätigt haben, dass sie das Geld tatsächlich erhalten haben.
Ich habe die Binance-Anleitung noch einmal gelesen und fand den Ablauf ziemlich klar. Beim Verkauf wird die Krypto in Escrow gehalten; der Verkäufer wartet, bis die Zahlung an die vereinbarte Methode eingeht, bestätigt dann, dass das Geld tatsächlich eingegangen ist, und gibt die Krypto erst danach frei.
Ich wollte verstehen, warum dieser Bestätigungsschritt vor der Freigabe steht, statt sich nur auf die Meldung „bezahlt“ zu verlassen.
Als ich zusätzlich die P2P-Sicherheitsdokumentation prüfte, wurde der Grund deutlicher. Binance warnt vor gefälschten Zahlungsbestätigungen und empfiehlt, das Empfangskonto direkt zu prüfen, statt Screenshot, Beleg oder SMS zu glauben.
Es stellte sich heraus, dass Escrow nicht bedeutet, dass der Verkäufer den letzten Verifizierungsschritt überspringen kann. Escrow hält die Krypto während der Transaktion zurück, aber ob das Fiat-Geld wirklich angekommen ist, muss dennoch vom Empfänger überprüft werden.
Im größeren Zusammenhang trägt bei P2P immer auch der Nutzer einen Teil der Verantwortung. Vielleicht liegt die Sicherheit bei P2P nicht darin, zu glauben, dass das System alle Risiken bereits vollständig abgefangen hat, sondern darin, die Dinge selbst noch einmal zu prüfen, die das System nicht an unserer Stelle bestätigen kann.
#binancep2pantoan @Binance_Vietnam $BTC
Ich bin einmal auf eine Situation gestoßen, durch die ich die Binance-P2P-Anleitung noch einmal lesen musste: Als ich nach dem Gewinn eines Airdrops von Binance Alpha 200 USDT verkaufte, schickte mir der Käufer einen Screenshot, der angeblich die Überweisung bestätigte, und drängte mich, die Krypto freizugeben. Auf den ersten Blick wirkte alles recht normal, aber als ich das Konto für den Zahlungseingang direkt überprüfte, stellte ich fest, dass das Geld dort noch gar nicht angekommen war. Aus dieser Situation heraus achtete ich auf einen weiteren Punkt in der Binance-Anleitung: Verkäufer sollten die Krypto erst freigeben, nachdem sie selbst bestätigt haben, dass sie das Geld tatsächlich erhalten haben.
Ich habe die Binance-Anleitung noch einmal gelesen und fand den Ablauf ziemlich klar. Beim Verkauf wird die Krypto in Escrow gehalten; der Verkäufer wartet, bis die Zahlung an die vereinbarte Methode eingeht, bestätigt dann, dass das Geld tatsächlich eingegangen ist, und gibt die Krypto erst danach frei.
Ich wollte verstehen, warum dieser Bestätigungsschritt vor der Freigabe steht, statt sich nur auf die Meldung „bezahlt“ zu verlassen.
Als ich zusätzlich die P2P-Sicherheitsdokumentation prüfte, wurde der Grund deutlicher. Binance warnt vor gefälschten Zahlungsbestätigungen und empfiehlt, das Empfangskonto direkt zu prüfen, statt Screenshot, Beleg oder SMS zu glauben.
Es stellte sich heraus, dass Escrow nicht bedeutet, dass der Verkäufer den letzten Verifizierungsschritt überspringen kann. Escrow hält die Krypto während der Transaktion zurück, aber ob das Fiat-Geld wirklich angekommen ist, muss dennoch vom Empfänger überprüft werden.
Im größeren Zusammenhang trägt bei P2P immer auch der Nutzer einen Teil der Verantwortung. Vielleicht liegt die Sicherheit bei P2P nicht darin, zu glauben, dass das System alle Risiken bereits vollständig abgefangen hat, sondern darin, die Dinge selbst noch einmal zu prüfen, die das System nicht an unserer Stelle bestätigen kann.
#binancep2pantoan @Binance Vietnam $BTC
Ich habe die Binance-Anleitung noch einmal gelesen und fand den Ablauf ziemlich klar. Beim Verkauf wird die Krypto in Escrow gehalten; der Verkäufer wartet, bis die Zahlung an die vereinbarte Methode eingeht, bestätigt dann, dass das Geld tatsächlich eingegangen ist, und gibt die Krypto erst danach frei.
Ich wollte verstehen, warum dieser Bestätigungsschritt vor der Freigabe steht, statt sich nur auf die Meldung „bezahlt“ zu verlassen.
Als ich zusätzlich die P2P-Sicherheitsdokumentation prüfte, wurde der Grund deutlicher. Binance warnt vor gefälschten Zahlungsbestätigungen und empfiehlt, das Empfangskonto direkt zu prüfen, statt Screenshot, Beleg oder SMS zu glauben.
Es stellte sich heraus, dass Escrow nicht bedeutet, dass der Verkäufer den letzten Verifizierungsschritt überspringen kann. Escrow hält die Krypto während der Transaktion zurück, aber ob das Fiat-Geld wirklich angekommen ist, muss dennoch vom Empfänger überprüft werden.
Im größeren Zusammenhang trägt bei P2P immer auch der Nutzer einen Teil der Verantwortung. Vielleicht liegt die Sicherheit bei P2P nicht darin, zu glauben, dass das System alle Risiken bereits vollständig abgefangen hat, sondern darin, die Dinge selbst noch einmal zu prüfen, die das System nicht an unserer Stelle bestätigen kann.
#binancep2pantoan @Binance Vietnam $BTC
1
174
Übersetzung ansehen
Có gì đó khiến tôi dừng lại khi đọc kiến trúc của Dusk Network. Ban đầu tôi vẫn nhìn nó như một Layer 1 quen thuộc: có consensus, smart contract, token và một hệ sinh thái được xây dựng phía trên.
Nhưng khi đọc kỹ hơn, cách Dusk chia các thành phần khiến tôi phải đọc lại từ đầu.
Docs của Dusk mô tả DuskDS là nền tảng settlement và data availability, chịu trách nhiệm consensus, finality và các transaction model của Dusk L1 còn phần execution được tách thành hai hướng: DuskVM cho Rust/WASM chạy trực tiếp trên L1 và DuskEVM cho môi trường EVM tương thích Ethereum.
Tôi bắt đầu đào sâu vì muốn hiểu đây chỉ là cách tổ chức lại một Layer 1 hay thực sự phản ánh một lựa chọn kiến trúc khác.
Điểm tôi tìm thấy khá rõ: Dusk không gom toàn bộ execution vào một môi trường duy nhất. DuskDS xử lý consensus, settlement và data availability trong khi DuskVM và DuskEVM đảm nhiệm những mô hình execution khác nhau.
Khoan, điều này vẫn chưa đủ để nói kiến trúc đó tốt hơn nhưng nó thay đổi cách tôi nhìn Dusk. Có lẽ câu hỏi thú vị hơn không phải “Dusk có phải một Layer 1 không?” mà là: việc tách settlement khỏi execution sẽ thực sự mang lại điều gì khi các execution environment này bắt đầu có usage đáng kể?
#dusk $DUSK @Dusk_Foundation $BTC
Có gì đó khiến tôi dừng lại khi đọc kiến trúc của Dusk Network. Ban đầu tôi vẫn nhìn nó như một Layer 1 quen thuộc: có consensus, smart contract, token và một hệ sinh thái được xây dựng phía trên.
Nhưng khi đọc kỹ hơn, cách Dusk chia các thành phần khiến tôi phải đọc lại từ đầu.
Docs của Dusk mô tả DuskDS là nền tảng settlement và data availability, chịu trách nhiệm consensus, finality và các transaction model của Dusk L1 còn phần execution được tách thành hai hướng: DuskVM cho Rust/WASM chạy trực tiếp trên L1 và DuskEVM cho môi trường EVM tương thích Ethereum.
Tôi bắt đầu đào sâu vì muốn hiểu đây chỉ là cách tổ chức lại một Layer 1 hay thực sự phản ánh một lựa chọn kiến trúc khác.
Điểm tôi tìm thấy khá rõ: Dusk không gom toàn bộ execution vào một môi trường duy nhất. DuskDS xử lý consensus, settlement và data availability trong khi DuskVM và DuskEVM đảm nhiệm những mô hình execution khác nhau.
Khoan, điều này vẫn chưa đủ để nói kiến trúc đó tốt hơn nhưng nó thay đổi cách tôi nhìn Dusk. Có lẽ câu hỏi thú vị hơn không phải “Dusk có phải một Layer 1 không?” mà là: việc tách settlement khỏi execution sẽ thực sự mang lại điều gì khi các execution environment này bắt đầu có usage đáng kể?
#dusk $DUSK @Dusk $BTC
Nhưng khi đọc kỹ hơn, cách Dusk chia các thành phần khiến tôi phải đọc lại từ đầu.
Docs của Dusk mô tả DuskDS là nền tảng settlement và data availability, chịu trách nhiệm consensus, finality và các transaction model của Dusk L1 còn phần execution được tách thành hai hướng: DuskVM cho Rust/WASM chạy trực tiếp trên L1 và DuskEVM cho môi trường EVM tương thích Ethereum.
Tôi bắt đầu đào sâu vì muốn hiểu đây chỉ là cách tổ chức lại một Layer 1 hay thực sự phản ánh một lựa chọn kiến trúc khác.
Điểm tôi tìm thấy khá rõ: Dusk không gom toàn bộ execution vào một môi trường duy nhất. DuskDS xử lý consensus, settlement và data availability trong khi DuskVM và DuskEVM đảm nhiệm những mô hình execution khác nhau.
Khoan, điều này vẫn chưa đủ để nói kiến trúc đó tốt hơn nhưng nó thay đổi cách tôi nhìn Dusk. Có lẽ câu hỏi thú vị hơn không phải “Dusk có phải một Layer 1 không?” mà là: việc tách settlement khỏi execution sẽ thực sự mang lại điều gì khi các execution environment này bắt đầu có usage đáng kể?
#dusk $DUSK @Dusk $BTC
1
2
150
Übersetzung ansehen
Có lần tôi bán crypto trên Binance P2P, người mua báo đã chuyển tiền và gửi ảnh chụp giao dịch thành công. Nhìn vào đó, mọi thứ gần như đã xong nhưng khi tôi mở ứng dụng ngân hàng kiểm tra, khoản tiền vẫn chưa xuất hiện trong tài khoản. Tôi dừng lại ở đó thay vì bấm Release vì lúc này một câu hỏi trở nên khá rõ: nếu người mua đã nói “đã chuyển” vậy thứ tôi cần xác nhận trước khi release crypto thực sự là gì?
Tôi thử đi ngược lại một giao dịch đơn giản. Người mua thực hiện thanh toán bằng phương thức đã thỏa thuận sau đó người bán kiểm tra khoản tiền nhận được. Tài liệu Binance ghi rõ: sau khi xác nhận tiền đã đến người bán mới release crypto khỏi escrow.
Tôi muốn hiểu vì sao bước xác nhận này lại được đặt ở phía người bán.
Khi đọc Merchant Guidelines, tôi thấy Binance còn yêu cầu tên trên tài khoản thanh toán phải khớp với tên đã xác minh trên nền tảng. Nếu thông tin tài khoản ngân hàng của đối tác không khớp với tên đã xác minh Binance yêu cầu không release crypto; người bán có thể hoàn tiền và báo cáo giao dịch.
Đến đây tôi mới nhận ra mình từng nhìn P2P hơi đơn giản. Escrow giữ crypto trong quá trình giao dịch nhưng việc xác nhận khoản thanh toán đã thực sự được nhận vẫn là một bước riêng trong quy trình.
Khoan, điều này không có nghĩa Binance có thể ngăn mọi rủi ro thanh toán. Tài liệu chỉ cho thấy trách nhiệm kiểm tra khoản tiền và thông tin người thanh toán vẫn tồn tại trước khi release.
Có lẽ “Release” không phải là thao tác xác nhận tiền đã đến mà là bước được thực hiện sau khi xác nhận.
Vậy nên trước khi release phải kiểm tra cẩn thận mọi người nhé.
#binancep2pantoan @Binance_Vietnam $BTC
Có lần tôi bán crypto trên Binance P2P, người mua báo đã chuyển tiền và gửi ảnh chụp giao dịch thành công. Nhìn vào đó, mọi thứ gần như đã xong nhưng khi tôi mở ứng dụng ngân hàng kiểm tra, khoản tiền vẫn chưa xuất hiện trong tài khoản. Tôi dừng lại ở đó thay vì bấm Release vì lúc này một câu hỏi trở nên khá rõ: nếu người mua đã nói “đã chuyển” vậy thứ tôi cần xác nhận trước khi release crypto thực sự là gì?
Tôi thử đi ngược lại một giao dịch đơn giản. Người mua thực hiện thanh toán bằng phương thức đã thỏa thuận sau đó người bán kiểm tra khoản tiền nhận được. Tài liệu Binance ghi rõ: sau khi xác nhận tiền đã đến người bán mới release crypto khỏi escrow.
Tôi muốn hiểu vì sao bước xác nhận này lại được đặt ở phía người bán.
Khi đọc Merchant Guidelines, tôi thấy Binance còn yêu cầu tên trên tài khoản thanh toán phải khớp với tên đã xác minh trên nền tảng. Nếu thông tin tài khoản ngân hàng của đối tác không khớp với tên đã xác minh Binance yêu cầu không release crypto; người bán có thể hoàn tiền và báo cáo giao dịch.
Đến đây tôi mới nhận ra mình từng nhìn P2P hơi đơn giản. Escrow giữ crypto trong quá trình giao dịch nhưng việc xác nhận khoản thanh toán đã thực sự được nhận vẫn là một bước riêng trong quy trình.
Khoan, điều này không có nghĩa Binance có thể ngăn mọi rủi ro thanh toán. Tài liệu chỉ cho thấy trách nhiệm kiểm tra khoản tiền và thông tin người thanh toán vẫn tồn tại trước khi release.
Có lẽ “Release” không phải là thao tác xác nhận tiền đã đến mà là bước được thực hiện sau khi xác nhận.
Vậy nên trước khi release phải kiểm tra cẩn thận mọi người nhé.
#binancep2pantoan @Binance Vietnam $BTC
Tôi thử đi ngược lại một giao dịch đơn giản. Người mua thực hiện thanh toán bằng phương thức đã thỏa thuận sau đó người bán kiểm tra khoản tiền nhận được. Tài liệu Binance ghi rõ: sau khi xác nhận tiền đã đến người bán mới release crypto khỏi escrow.
Tôi muốn hiểu vì sao bước xác nhận này lại được đặt ở phía người bán.
Khi đọc Merchant Guidelines, tôi thấy Binance còn yêu cầu tên trên tài khoản thanh toán phải khớp với tên đã xác minh trên nền tảng. Nếu thông tin tài khoản ngân hàng của đối tác không khớp với tên đã xác minh Binance yêu cầu không release crypto; người bán có thể hoàn tiền và báo cáo giao dịch.
Đến đây tôi mới nhận ra mình từng nhìn P2P hơi đơn giản. Escrow giữ crypto trong quá trình giao dịch nhưng việc xác nhận khoản thanh toán đã thực sự được nhận vẫn là một bước riêng trong quy trình.
Khoan, điều này không có nghĩa Binance có thể ngăn mọi rủi ro thanh toán. Tài liệu chỉ cho thấy trách nhiệm kiểm tra khoản tiền và thông tin người thanh toán vẫn tồn tại trước khi release.
Có lẽ “Release” không phải là thao tác xác nhận tiền đã đến mà là bước được thực hiện sau khi xác nhận.
Vậy nên trước khi release phải kiểm tra cẩn thận mọi người nhé.
#binancep2pantoan @Binance Vietnam $BTC
1
3
346
Übersetzung ansehen
Có gì đó khiến tôi dừng lại khi đọc về Dusk Network: DuskDS và DuskEVM được mô tả như hai phần khác nhau nhưng lại không đứng độc lập.
Tôi bắt đầu từ kiến trúc. Tài liệu Dusk gọi DuskDS là lớp settlement và data availability, đảm nhiệm consensus, finality và các transaction model native của Dusk. DuskEVM là môi trường execution tương thích EVM, nơi smart contract Solidity có thể chạy bằng tooling quen thuộc. Quan trọng hơn, DuskEVM sử dụng DuskDS cho settlement và data availability.
Tôi muốn kiểm tra xem đây chỉ là cách gọi mang tính kiến trúc hay có sự phân tách trách nhiệm.
Đọc sâu hơn, tôi thấy DuskDS xử lý consensus, finality và data availability cùng các transaction model như Moonlight và Phoenix. DuskEVM tập trung vào execution và cho phép dùng Hardhat, Foundry cùng hệ sinh thái EVM. Một bên cung cấp nền tảng settlement, bên kia đảm nhiệm execution.
Khoan, điều này vẫn chưa đủ để nói hai lớp “bổ trợ” nhau theo nghĩa hiệu năng hay bảo mật. Từ tài liệu tôi kiểm chứng được, quan hệ rõ nhất là execution được tách khỏi settlement.
Điều thú vị là Dusk dùng modularity để giữ settlement riêng nhưng vẫn mở cửa cho developer bằng EVM.
Vậy nếu application adoption tăng, ranh giới giữa execution và settlement này có thực sự tạo ra lợi thế hay chỉ đơn giản là một cách tổ chức kiến trúc?
#dusk $DUSK @Dusk_Foundation $BTC
Có gì đó khiến tôi dừng lại khi đọc về Dusk Network: DuskDS và DuskEVM được mô tả như hai phần khác nhau nhưng lại không đứng độc lập.
Tôi bắt đầu từ kiến trúc. Tài liệu Dusk gọi DuskDS là lớp settlement và data availability, đảm nhiệm consensus, finality và các transaction model native của Dusk. DuskEVM là môi trường execution tương thích EVM, nơi smart contract Solidity có thể chạy bằng tooling quen thuộc. Quan trọng hơn, DuskEVM sử dụng DuskDS cho settlement và data availability.
Tôi muốn kiểm tra xem đây chỉ là cách gọi mang tính kiến trúc hay có sự phân tách trách nhiệm.
Đọc sâu hơn, tôi thấy DuskDS xử lý consensus, finality và data availability cùng các transaction model như Moonlight và Phoenix. DuskEVM tập trung vào execution và cho phép dùng Hardhat, Foundry cùng hệ sinh thái EVM. Một bên cung cấp nền tảng settlement, bên kia đảm nhiệm execution.
Khoan, điều này vẫn chưa đủ để nói hai lớp “bổ trợ” nhau theo nghĩa hiệu năng hay bảo mật. Từ tài liệu tôi kiểm chứng được, quan hệ rõ nhất là execution được tách khỏi settlement.
Điều thú vị là Dusk dùng modularity để giữ settlement riêng nhưng vẫn mở cửa cho developer bằng EVM.
Vậy nếu application adoption tăng, ranh giới giữa execution và settlement này có thực sự tạo ra lợi thế hay chỉ đơn giản là một cách tổ chức kiến trúc?
#dusk $DUSK @Dusk $BTC
Tôi bắt đầu từ kiến trúc. Tài liệu Dusk gọi DuskDS là lớp settlement và data availability, đảm nhiệm consensus, finality và các transaction model native của Dusk. DuskEVM là môi trường execution tương thích EVM, nơi smart contract Solidity có thể chạy bằng tooling quen thuộc. Quan trọng hơn, DuskEVM sử dụng DuskDS cho settlement và data availability.
Tôi muốn kiểm tra xem đây chỉ là cách gọi mang tính kiến trúc hay có sự phân tách trách nhiệm.
Đọc sâu hơn, tôi thấy DuskDS xử lý consensus, finality và data availability cùng các transaction model như Moonlight và Phoenix. DuskEVM tập trung vào execution và cho phép dùng Hardhat, Foundry cùng hệ sinh thái EVM. Một bên cung cấp nền tảng settlement, bên kia đảm nhiệm execution.
Khoan, điều này vẫn chưa đủ để nói hai lớp “bổ trợ” nhau theo nghĩa hiệu năng hay bảo mật. Từ tài liệu tôi kiểm chứng được, quan hệ rõ nhất là execution được tách khỏi settlement.
Điều thú vị là Dusk dùng modularity để giữ settlement riêng nhưng vẫn mở cửa cho developer bằng EVM.
Vậy nếu application adoption tăng, ranh giới giữa execution và settlement này có thực sự tạo ra lợi thế hay chỉ đơn giản là một cách tổ chức kiến trúc?
#dusk $DUSK @Dusk $BTC
7
4
91
Anmelden und weiter Inhalte entdecken
Krypto-Nutzer weltweit auf Binance Square kennenlernen
⚡️ Bleib in Sachen Krypto stets am Puls.
💬 Die weltgrößte Kryptobörse vertraut darauf.
👍 Erhalte verlässliche Einblicke von verifizierten Creators.
E-Mail-Adresse/Telefonnummer
Trendthemen
BitgetHackerMoves$83MStolenXRP
224 Aufrufe
20 Kommentare
#BitgetHackerMoves$83MStolenXRP 📊 Marktupdate: Bitget-Hacker bewegt 83 Mio. $ an gestohlenem XRP – Auswirkungen auf das Ökosystem
On-Chain-Aktivitäten zeigen, dass der Angreifer hinter der jüngsten Bitget-Panne begonnen hat, einen erheblichen Teil des gestohlenen XRP zu verlagern. Hier ist eine klare, objektive Aufschlüsselung der Lage und dessen, was es für den breiteren Kryptomarkt bedeutet.
📰 Zentrale News
• 💸 Mittelbewegung Rund 83 Millionen US-Dollar in XRP wurden aus drei mit der ~387,5 Millionen US-Dollar schweren Bitget-Sicherheitsverletzung verknüpften Verwahrungs-Wallets transferiert. Etwa 75 Millionen US-Dollar verbleiben in den ursprünglichen Konten.
• ❄️ Einschränkungen durch Freeze Während Stablecoin-Emittenten wie Circle und Tether die zugehörigen USDC/USDT erfolgreich einfrieren konnten, kann das native XRP nicht von Ripple oder irgendeiner zentralen Stelle eingefroren werden, da die grundlegende Funktionsweise des XRP Ledger dies nicht vorsieht.
• 🛡️ Reaktion der Börse Bitget hat bestätigt, dass sein Schutzfonds die Verluste vollständig abdecken wird. Die Kundenguthaben bleiben unverändert, und gestaffelte Auszahlungen sollen in Kürze wieder aufgenommen werden.
📈 Marktauswirkungen
⚖️ Preisstabilität XRP zeigte sich relativ stabil und hat die Nachricht mit nur geringer kurzfristiger Volatilität absorbiert. Der Markt scheint einzupreisen, dass die Nutzerfonds durch den Reservefonds der Börse geschützt sind.
• 🔍 Sicherheits-Erkenntnis Dieser Vorfall macht einen wichtigen technischen Unterschied in der Krypto-Welt deutlich: Native Layer-1-Assets verfügen nicht über integrierte Freeze-Mechanismen. Das zeigt den weiterhin bestehenden Bedarf der Branche an fortgeschrittenen Custody-Protokollen für Exchanges, Multi-Sig-Lösungen und Echtzeit-On-Chain-Überwachung.
💬 Diskutiere mit
Wie denkst du, sollte die Kryptoindustrie das Kernprinzip dezentraler, zensurresistenter Netzwerke mit der Notwendigkeit von Sicherheitsnetzen bei großen Sicherheitsvorfällen in Einklang bringen? Teile deine Gedanken unten! 👇
#XRP #CryptoSecurity #Bitget #Blockchain #CryptoNews
Dies dient ausschließlich zu Bildungszwecken. Keine Finanzberatung (NFA). Mach immer deine eigene Recherche (DYOR).
$QNT $GLMR $AMP.US
珍妮丝 kgf
·0 Likes
·19 Aufrufe
SOLSpotETFWeeklyInflow$188M
252 Aufrufe
34 Kommentare
StrategyStriveAdd2305BitcoinThisWeek
28,779 Aufrufe
870 Kommentare