Network Architectural Overview of dApp w/ DKM

Decentralized Key Management

A NodeJS framework for HotPocket clusters to manage their XRPL account signer keys in order to use the XRP Ledger in a decentralized manner. The Decentralized Key Management framework or the DKM framework facilitates the management of a dApp's XRPL multi-sig account.

DKM is available for installation on npm:

npm install decentralized-key-management

Inspiration

While me and a few developers were coding our respective decentralized applications on Evernode, we were all faced with a similar issue related to signer key management on our dApp's XRPL account.

Each HotPocket decentralized application wanting to provide a service on the XRP Ledger requires them to own and manage their XRPL accounts in a decentralized manner. With that in mind, we needed to develop our own respective frameworks or use an open source framework that manages their dApp's XRPL account's signer keys.

I took the initiative to resolve this early stage problem by proposing the Decentralized Key Management framework that provides dApps the foundational features to manage their XRPL account's signer keys in a flexible manner without standardized and unnecessary constraints set by the framework.

Utilizing DKM allows developers to focus on designing and developing their dApps without needing to put up monumental amounts of resources and time to develop their own framework for signer key management.

It is also important to note that DKM is open source and a community effort. Over time, improvements and fixes will be made by community members to patch any bugs or exploits that are found.

What it does

The Decentralized Key Management framework currently provides HotPocket dApps the foundational features to sign XRPL transactions (signature distribution and collection) and manage their XRPL account's SignerList according to the dApp's network state.

When the dApp wants to sign and submit a transaction to the XRP Ledger, nodes would first construct the transaction with similar common values (fee, sequence, amount, etc).

The dApp would then call DKM.SignTx(): which would instruct the node to locally sign the transaction using its own private key. The node would then proceed to use the unsigned transaction's hash as a checksum for a NPL round to distribute and collect signatures from its peers. For instance, the node would distribute this to all its UNL peers.

{"account":"rhbxbtzcMBgjYxo5t8uT61Pv3RK2P7DovJ","tx":"120000220000000024022D01BC201B022D028B61400000000000002B6840000000..........564207573696E6720444B4D206F6E206120486F74506F636B657420636C757374657220696E204C656467657220343320217E08746578742F637376E1F1"}

What's a "NPL Round", you may ask? It's a sub-consensus round that occurs on the P2P mesh network where nodes communicate and relay arbitrary data!

If a node is able to collect a sufficient amount of signatures during the NPL round which meets the signer quorum on the dApp's XRPL account. It would submit the multi-sig tx blob to a rippled node for validation.

How we built it

Due to the fact that most HotPocket developers are using NodeJS, DKM is developed as a npm package.

Challenges we ran into

There were a number of credible technical challenges that came with developing DKM as the ecosystem is very young and it's a new approach to decentralized applications since we're dealing with direct P2P consensus, UNL management & state synchronization. So I'll be highlighting 1 challenge that was a worthy opponent!

UNL Management: synchronization with DKM. As HotPocket dApps may follow different approaches for their network's consensus and network governance, I had to figure out which consensus protocol works best for DKM's current approach.

I'd conclude that DKM works best with a HotPocket network that has a UNL overlap of more than 80% as nodes that have their signer keys apart of the dApp's XRPL account SignerList would need to collect enough signature, it is significantly important for them to be in a state of high connectivity for a higher chance of collecting enough signatures.

Accomplishments that we're proud of

I'm proud of being able to provide this package to the Evernode developer community at such an early stage. Many dApps would rely on this framework if it were to be deemed consistent and reliable.

Of course, I shouldn't be the only person that's proud of this initiative, many will be as it's a community effort.

What we learned

I was able to further sharpen my understanding on everything distributed systems. In relation to Evernode and HotPocket, a HotPocket dApp is not your average "crypto focused" distributed system. It is a flexi consensus engine that powers distributed systems with many goals and use cases, outside of crypto. Evernode is not limited to crypto, it's trying to commercialize distributed systems.

What's next for Decentralized Key Management [Evernode]

Simply put, we plan on pushing for more improvements based on developers' comments and opening up direct community collaborations to further expand the framework's maintainer group.

While I'm participating in this hackathon with this project, I am 110% continuing this initiative after the hackathon concludes as it is a detrimental piece of infra code to HotPocket dApps that want to utilize and integrate with the XRP Ledger either as a standard user or a decentralized application, providing a certain service.

To sum it all up, the Decentralized Key Management framework enables HotPocket decentralized applications to provide a plethora of services in a decentralized and trustless manner on the XRP Ledger, for example:

Decentralized Finance
Privacy and Security
Web3
Infrastructure
Multichain

Currently, DKM only supports XRP Ledger Protocol-powered networks. Additional support for other chains or cryptographic schemes may be met if demand is met, but right now it's best to focus on sharpening the current code/protocol to ensure that it's stable & secure for production use.