Velas Technologies: MicroApps
Today, most app developers are shifting their focus to micro-service architecture. The most desired features of software solutions are performance and flexibility, and by applying predefined blockchain rules, structures are implemented that control how data is interacted with. Applications, however, remain the primary interface for end-users, where security and usability are developers’ pain point.
Security
The “client instance” interacts with the front-end Dapp and acts as the constructor of the smart contract transaction, visually describing what the user is doing.
Just as an example of this in practice: the publishing of a smart-contract is allowed in the Ethereum blockchain, but wallets with the web3 protocol support user will need to interact. This Wallet locally recreates “client instance of the contract”, interacting with the user and the smart contract to perform different operations.
The launch of the designer can be divided between:
- The client code of the application/ wallet
- The Browser
- The Dapp Browser
The wallet interacting with the smart contract should be publicly verified for:
- The working capacity (compliance of the declared logic with the programmed logic)
- The safety of the smart contract as a whole
Usually, to become an arbitrator between anonymous users, smart-contracts should pass an audit before publication. The same is true on the client side, it should pass a security audit, interacting with the smart-contract.
Therefore, all wallets that interact with smart-contracts are published with open source code and each user can check the correct implementation of the wallet code.
Examples of this can be seen at:
https://github.com/MetaMask/metamask-extension
https://github.com/trustwallet/wallet-core
https://github.com/AlphaWallet/alpha-wallet-android
How to prove that the wallet matches the code on Github?
There is an additional option to verify the uploaded wallet, if it is:
- Located inside the browser page
- Loaded as a browser extension
- Installed from direct sources
But, all these methods are available only to qualified users. Average users, who are not familiar with programming, have to trust brands and public ratings.
If you download the wallet as a mobile application, there is no proof.
The only thing the user can receive is the resulting hash (which has been checked by experts) after the point of compilation and then compare it with the binary file of the application they use.
How to confirm that the code has no errors on Github?
Since an individual specialist can make a mistake and miss an error, the only correct way to verify that the code works properly is to test real transactions within the time, and the code should be left unchanged.
Any modification should be checked: immutability is a smart-contract feature, but not a client logic, at the same time developers may modify client logic without any regulations.
But this level of verification requires writing UNIT tests for any positive or negative case, and full coverage of the tests increases the complexity of developing a software solution exponentially.
Each variant of use requires a wide range of testing options, and each variant of testing requires writing a significant amount of UNIT tests. Finally, one needs to test the correctness of the description of the use cases, the set of test cases, and the set of UNIT tests.
Only technical specialists who have a good understanding of the business process and the precise setting of the task can carry out this work.
Alas, this process is almost never 100 percent complete, because:
- Tasks are not clearly set, because of the dynamics of the industry, to create solutions in time for the experiment on the hot market.
- Describing by tests is not stable to principal changes in code. Each time you change the code, you must start the entire process anew.
- Written code may be difficult or unsuitable for full testing.
- According to NDA conditions, the team keeps the development secret and can’t pass it onto auditors for verification.
- Auditors don’t guarantee 100% quality of audit.
Conclusion: The trust in software for an average user is formed by an error-free code strategy.
Cross-Platform
Any and all Dapp applications arelimited to those platforms on which they run. To increase user coverage, the developer needs to write an application for all platforms like IOS, Android, Windows, macOS, Linux, and so on.
All applications should strictly match each other, although they can be developed in different programming languages, taking into account the different features of the platform they are launched on.
All applications should include the following features:
- Determinism — application functions have to return the same result with the same input.
- Functionality matching — even if the application looks different, the user should still access the functionality that the same application has on a different platform.
It is much easier to write multi-platform code, taking into account the specifics of the platforms and, as a result, it will have the same functionality for users with different preferences of OS and devices.
Usability
Let’s take a deeper look at Telegram Bots. This functionality implements cross-platform, because the Telegram client is available on all platforms and contains this functionality equally across all of them.
Development of Telegram Bots should not depend on specifics of the device where the bot is launched, because all this work has already been done.
There are some limited possibilities for the developer working with Bots:
- Text
- Picture
- Buttons
- Tips
- Request Location
- Request Contact
- Sending files
- Sending text
- Send commands — ‘click on buttons’
With this feature, a developer can repeat the functionality of his application in a bot, but with account to the restrictions imposed by the Telegram application.
Decision
According to the analysis on the use of Browser and Mobile — 75% of users prefer mobile devices more than a desktop based browser. And if we analyze the use of applications on mobile, users are 75% more likely to use chat rooms than other applications.
Therefore, the problem of safe cross-platform and convenient applications should be solved in the chat rooms, so that the user doesn’t have to apply anything else.
Velas’ solution is to develop cross-platform and built-in chat applications that meet all levels of security and convenience.
Velas provides:
- The Decentralized storage of components
- Chat, where these components can be involved
Storage function:
- Guaranteed component invariance
- Storage warranty of components for a period determined by the developer (at least one year)
- Providing components of a chat client application on demand
- Evidence of code authenticity (no possibility of falsifying).
Chat Functions:
- Playing a component as a visual chat element interacting with a user
- Providing the API of the chat:
- Location Request
- Contact Request
- Payment Request
- Auth Request
3. Providing isolated storage for the component, to enable user interaction with the component
The development process of Velas microApps:
- The development of components following the rules of the code convention
- The developer publishes the application in VelasSphere
- The developer creates a Telegram bot, that, instead of text, sends the user a link to the address where his application is located
- Telegram downloads the application from the link and plays it in client chat.
- The user interacts with the application, with the certainty that the developer (no one else) can’t change it anymore.
- In case an application uses decentralized services, it becomes fully decentralized and resistant to censorship.
This is one of a series of articles outlining the complete package of Velas products on offer, and what the team has been working hard on over the past year. We’re covering everything from AIDPOS to Integrated Crypto Wallets and everything in between. You don’t want to miss it!
