Nowadays, during a pandemic period, when many industries struggle and only those that can operate remotely can still stay afloat, digitalization is making a big leap. In the real estate industry, where realtors are forbidden to meet customers in person due to the current circumstances, property transactions can only take place online. In the future, more data will be exchanged remotely, and complex high-value transactions will be brought online; meaning industries will be more vulnerable to cyberattacks.
Transaction Automation in Real Estate
At Propy, we believe that the next big thing in the real estate field is transaction automation, which is supported by many industry leaders, such as Brad Inman, Paul Levine, and others. Transaction automation is being developed in a comprehensive form as a complete settlement system. The settlement process includes executing the purchase agreement, handling payments, and, ultimately, transferring the ownership of the property.
Our platform offers tools that allow one to automate the entire property settlement process, which is especially sensitive when it comes to security. In this demo video, you can overview the platform’s user interface and features. Our engineers found the work during this particular development stage to be especially exciting and challenging, as the team had to find unique solutions to make the working application safe, cost-effective, and easy-to-use. Additionally, blockchain is still a relatively recent technology; thus, we have been facing a steep learning curve, which requires us to perform a large amount of analysis and digest new information.
The most exciting part of the process is that we have been able to try many new and unique approaches, as there are very few “best practices” available in the market. Moreover, the fact that Ethereum’s smart contracts are available to the public means that participation in some open source projects is much easier.
Data and Transparency
As blockchain developers, we aim to store data safely and transparently. However, as our products use confidential information and the end user is subject to human errors, we need to be more flexible and introduce user identity recovery features that are not at odds with our main goals (i.e., security and transparency). For example, we are encoding the user’s key into a password-secured JSON envelope; our apps never get access to the raw key. We unpack the envelope only on the front end.
Just like every company, we strive to achieve self-sufficiency and independence. Therefore, we want to keep all of the necessary tools, such as Ethereum nodes, onsite. However, keeping the node cluster stable requires a lot of resources and the development of many non-trivial services, forcing us to use cluster services such as Infura, Alchemy, and so on, which offer subscription plans depending on the number of requests that we perform to hit the API. In such cases, when interacting with the nodes in the Ethereum network, we need to be economically rational and ensure the optimum level of benefits while minimizing our costs.
Another big challenge is that Ethereum has a mechanism to protect against reusing user signatures, and it requires sending transactions synchronously to include a serial number called a “nonce.” The arrangement makes the whole transaction processing module non-trivial and, at the same time, potentially more prone to bugs. However, it should work very accurately.
Furthermore, the price of a transaction on Ethereum is highly correlated with the network load. Therefore, we are working hard to optimize our code in such a way that we are ready to meet urgent business needs while using the least amount of computational power. In business, we are always confronted with a trade-off between price and flexibility while trying to find the right balance under specific constraints. The user does not interfere with the crypto payment, as we are focusing on traditional realtors and consumers who acquire properties in dollars. However, when an account is created with an associated smart contract, we buy tokens from the market on the user’s behalf; then, we send the tokens to the smart contracts and use the tokens to cover gas fees.
Unique Approaches That Have Solved Technical Challenges Connected to Blockchain
At Propy, we have created a set of API microservices to be used by the “business” logic apps. This set of microservices is constrained, on the one hand, by the fact that the transaction processing is not trivial and that numerous requests must be made to the blockchain, and, on the other hand, the fact that we can not support our own node cluster.The service is responsible for delivering the blockchain transaction and checking the status of the blockchain’s listening, nonce management, and sync nodes. However, while we are still reliant on third parties in terms of nodes, we have significantly reduced the number of requests to the API (and, therefore, the subscription costs that we pay).
Furthermore, the flexibility of the system is very important for reducing the time resources required by the team. The so-called “Proxying” approach is used to autotomize the blockchain contract updates from the applications and services that we use. Our services interact with a Proxy contract that forwards the transactions to the “Implementation” contract.
Another solution that we have introduced relates to covering transaction costs on behalf of our customers, (i.e., in cases when a customer needs to modify data in the smart contract that is only possible only with his or her identity or signature). To avoid overcomplicating the user experience, we avoid having the end user cover the execution costs. Instead, we send the transaction on behalf of the customer. So, we introduced “Forwarder” / “Double Signer” contracts that allow the customer to pre-sign the off-chain payload transaction and send it to our system before the system sends it to the blockchain. On-chain, we validate both signatures and forward it to the “Implementation” contract, where the desired action is finally executed (if everything matches).
Three Items That the Blockchain Community Can Learn From Propy’s Experience
Undoubtedly, the most significant advantages of blockchain-based services are transparency, data immutability, and integrity. However, in some cases, it is better to use private blockchains to protect data privacy and security for business-level use cases. In this model, the identities of the participants who are allowed to maintain the ledger and execute the consensus protocol are known. Because such a blockchain is lighter, it provides transactional throughput that is orders of magnitude higher than those of public blockchains. There are already some attempts to implement this (for example, Corda by R3); however, the model requires running all the infrastructure basically “on-premise,” potentially giving rise to some vulnerability as centralization allows the data to be rewritten within the system. In our opinion, some functionalities of private blockchains and some “out-of-the-box” features (like libraries) can be implemented in Ethereum or other public blockchains. Therefore, there is a lot more for the blockchain community to work on and try to achieve.
Since blockchain technology is relatively new, we still lack a lot of resources, such as IDEs and utilities, that make the tech more workable. Even though there are currently great tools as Truffle and Remix, if we compare the infrastructure with more mature technology (like Oracle, Java), it is obvious that there is a lot to improve. For example, there is the possibility of using transaction sending services in addition to the node cluster services to relieve the business logic from the aforementioned complicated processing routines. (By the way, we are currently developing such a service.)
Authors: Natalia Karayaneva, Denis Kurochkin, Jonathan Haas