Hi guys,
In this blog post, we’re going to tell you about our plans for the following week. But, firstly, let’s summarize our previous week: what we’ve achieved and what haven’t.
Previous week
Internal testing of the new decentralized version of OptriSpace
We started our internal testing on Tuesday and found some uncovered cases which should be solved before public release comes. For example, when we used a centralized backend (Golang + PostgreSQL) we needed to use two-phase commits to achieve consistency between our backend and smart contracts on the blockchain. It worked like this: the user initiates a transaction via MetaMask in the web browser and when the transaction is completed, the user sends a confirmation request to our backend to validate the state on the blockchain. Two clicks for one action (accept the contract, fund, approve, etc.) don’t look good for user experience.
When we have been working on rewriting our application to the blockchain (and getting rid of the centralized backend) we, unfortunately, forget about two-phase commits (because we don’t need it at all), but we still use similar behavior. We will explain in more detail in the following article about our architecture and design decisions. Long story short, we deploy each smart contract between customers and freelancers and then add a copy (representation) of each contract to our Storage contract.
At this step we forgot about having copies of contract data inside our Storage and all data has been managed by an escrow smart contract. In User Interface, participants interact only with their own escrow smart contracts and our general smart contract doesn’t even know about the current state of their smart contracts (except blockchain address and some meta information). And it was a wrong decision for us because we would like to have a feature, like filtering a person’s smart contracts by status, or using contract states to render specific buttons or user interface elements. Because of this, we decided to store escrow contract data only in our Storage contract and escrow contracts will only store customers’ money (and have some business logic).
Now we need to add more tests to cover these cases to make sure that everything works perfectly. It takes about 2-3 days, and then we will be ready to continue our internal testing. To this day we’ve covered 4 (create, accept, fund, start) of 9 functions (deliver, confirm, decline, withdraw, refund).
Because of the explanation above, we didn’t deploy our platform to testnet and didn’t invite our community members to test the platform. We will be fully focused on this task this week.
Publish the task for copywriters with the winner of “Topic of the month”
We did this and have 9 applications from our community members. Not bad! When we get a response from our candidates, we would publish their posts on our blog in the Community Posts category.
Prepare requirements and publish tasks for Smart Contracts Auditor, Frontend Developer and Node Owner
In the last week, two software development companies contact us on LinkedIn and suggest their services to help us solve existing tasks and issues. We would like to meet these companies ASAP and see how they can help us.
About Frontend Developer: we have one guy in our Discord community who helped us before with frontend tasks and we want to talk to him.
Node Owner? Not yet, sorry.
Plans for this week
- Continue internal testing
- Invite community members to test our platform
- Publish three new posts on blog:
- Community member’s post (Wednesday)
- Technical article about our smart contracts architecture (Friday)
- Comparison table (Saturday)