What is Next?
... from alfa( α ) to beta( β ) AND from kappa( κ ) to sigma( σ )
Last updated
Was this helpful?
... from alfa( α ) to beta( β ) AND from kappa( κ ) to sigma( σ )
Last updated
Was this helpful?
As science fiction readers with tech skills, we can imagine a futuristic distributed system where everything are just coordinated ZEC transfers carrying encrypted action messages and metadata on MEMO fields.
For example, today, the weak side of privacy in Moeda are the known liquidity providers, who needs to send the private bank_history metadata, so the system can detect a payment was done to execute the ordered Contract. This could be wisely solved with an extended logic on top of the Zcash node on the Provider's side, as a layer, privately reading his own bank account history, observing new payments and sending a payment_done event:message to the pool's zaddr. We call it a Smart Node. In practical terms: if Moeda encodes the Contract UUID in the QRCode to the buyer, paid to the Agent, then, when the traditional payment is received with an identifier, this could be sent as a ZEC encrypted transaction to Moeda Smart Node as a proof it was received, and the Contract is executed with no need to know their bank history, in the Zero-knowledge spirit :D
Moeda started to conceptualize a Sentinel framework, observing and acting upon the received MEMO messages of up to 512 bytes to a node. ZecPages is an interesting example on how people can LIKE or REPLY messages, as some basic message-oriented (or event-based) architecture using Zcash as a distributed privacy layer. They could also benefit from our framework, being able to abstract a Smart Node logic, focusing all development effort on the Board logic itself.
We had an exponential to-do list of tasks while developing Moeda, some we had to deprioritise - thankful for some project management collaboration, or we would still be playing around with the Nodes having triggered events from MEMO messages.
Practical next steps are,
While, theoretically, our server+database can handle 300 requests per second, and Oracle & Swaps seems to run well coordinated on a few Threads, a basic Chaos Engineering evidences we need a proper asynchronous Message Queuing to handle it all before things scale out.
We would like to prepare for concurrent Contract requests before an official launch.
Websockets!
Prices should change on the front-end as they change on the back-end.
So do the Contract's status after a QR-Code is paid.
DevOps
precompile assets for deploy
oracle workers as systemd.services
basic DDoS protection on NGINX
Docker image + scripts for a suddenly server change
keep server sockets alive for active connections during a new deploy
Our Dev to-do list has many open tasks and ideas to refine the system as a hole.
UX
checkbox to "hide wallet address" on QR-code page
so "other payer" can become the buyer, unaware of Contract's wallet destination.
Contracts ($BRL->$XYZ orders) could be generated to third-party processes
Enhance CSS for mobile users
Adapt as a Progressive Web App
Test! Test! Test! Test! Test! Test!
We also imagined an ~200-token to Shielded-ZEC Swap service, abstracting parts of our system.
