Smart contract operation in Privatix Network

Semi-technical content. Please send any questions, thoughts and improvement suggestion to andrei@privatix.io or leave comment to this article.

Ethereum smart contracts playing fundamental role in Privatix DApp architecture. Currently we have already deployed smart contract that holds all PRIX tokens. We call it Privatix Token Contact (hereinafter PTC). This contract is compliant with ERC20 standard.

PTC WILL BE USED FOR:

• Token exchange
• As a middle point for upgrade to another contract with additional logic and features

Privatix will deploy additional smart contract named Privatix Service Contract (hereinafter PSC). PSC contract implements state channels feature, service offering discovery, helps to negotiate on service setup, incentivize fair usage and controls supply visibility.

Token exchange between Ethereum accounts is done using standard ERC20 transfer mechanism. PTC balances will be used to buy and sell PRIX only, rather than pay for services. To use Privatix services PRIX tokens will be approved for transfer to PSC contract address effectively delegating all operations to PSC contract.

PSC WILL BE USED FOR:

• Local balance storage
• Agent service offering registration and deposit placement
• Agent service offering deactivation and deposit return
• Retrieving available supply for service offering
• Pop up service offering
• Creating state channel
• Cooperative close of channel
• Uncooperative close of channel
• Top up deposit of state channel
• State channel performance

To save Ethereum gas and decrease time, which is required to setup state channel, PSC will maintain its own balance mapping. This mapping will hold mapping of PRIX to user’s balances until user will decide to move PRIX balance back to PTC. For that purpose, PSC will have mechanism to return back tokens from PSC to user’s Ethereum address in PTC. Making PSC operations rely on internal balances greatly improves security by preventing external contracts to execute arbitrary code thus mitigating reentrancy attacks.

Smart contract upgrade

To support future upgrade of PSC logic and features, while giving users ability to control and audit such changes, following upgrade path is planned. Privatix company may publish new version of PSC (e.g. version 2.0) in future. Users would verify smart contract code and if agreed, that it is safe to use, will firstly transfer their PRIX tokens from PSC v1.0 back to PTC and only then to PSC v2.0. Such approach leaves no back-doors even for Privatix employees and gives anybody ability to review new smart contract code before they switch to it. Privatix company may implement PSC.upgrade() function, which can be executed only by Privatix company. This function will prevent incoming transactions from PTC to PSC, but will still allow transfer of balances back to PTC. This method can be used as notification of smart contract upgrade to users’ UI, as well as pushes users to perform upgrade.

Service supply

Service supply is maximum number of concurrent Clients that Agent can serve with same service offering parameters. When Agent registers his offering in PSC he will specify service supply as well. Publishing service supply will allow Clients to find out, if Agent still has available supply to serve the Client according to published service offering. Before state channel is created, PSC will check, if available supply still exists and keep demand and supply balanced. After state channel was created PSC will emit event with actual service supply, making possible for all users to filter out offerings with zero supply. If state channel is closed, service supply will be increased and users notified.

“Sybil attack” mitigation

Sybil attack mitigation in decentralized networks, where at least some degree of anonymity expected is not obvious. We are not informed on any bullet proof technology to mitigate Sybil attack completely and without introducing some entrance threshold. Most used techniques today are proof of work, proof of stake, one-time fee, IPv4 address binding.

MALICIOUS AGENT

To maintain network health and incentivize fair usage, we will require Agents to register their service offering in Ethereum blockchain and place deposit. This deposit can be returned back after some challenge period is passed from last operation with this service offering. This step should protect Privatix network from easily being overwhelmed with junk offerings and make Sybil attack less efficient.

Agent Deposit should be proportional to service supply. If malicious Agent will place useless offering, that he never goes to fulfill, he will be required to place exactly same deposit as Client should place to accept this offer. On the other hand, as time passes from initial service offering registration, Clients will more likely to consider that this offering is no more actual. Therefore, Agent will need to notify Clients from time to time that his offer is still alive by popping it up in the list of recent offerings. When Agent pop-ups his offering, deposit lock will be restarted for new challenge period. As pop-up operation still makes it cheaper for Agent to spoil service offerings list, Clients will make additional consideration before accepting an offering. Long running offering can be easily rated by comparing number of cooperative channel closes (closed by Agent) with uncooperative (closed by Client). If Client created state channel, but didn’t receive any service he will be forced to make uncooperative channel close to get his deposit back. Any closure of state channel result in event generation that includes at least addresses of Client, Agent, type of event and balance paid. So, in case Client want to decide about malicious Agent’s offering (especially popped-up) he will see that there are too many uncooperative closes compared to cooperative once and will not create new state channel with this agent. This will require for malicious Agent to create new Agent address, transfer tokens and register new service offering. Such malicious operation is expensive and not effective.

If Agent will try to act both as Agent and Client to increase number of cooperative closes, it will cost him additional transaction fees. Moreover, each time he will act as Client he will reduce available supply for his service offering. In this case he need to occupy at least half of maximum supply to make number of cooperative closes equal to number of uncooperative closes. This forces him to place x 1.5 deposit than locked by normal Clients and still his reputation is far from being perfect.

We can summarize that Sybil attack by Agent is limited with Agent token balance, by challenge period and burns Ether with transaction cost.

MALICIOUS CLIENT

To harm Agent’s reputation malicious Client can create state channel and will not send balance proofs to Agent. When creating channel, Client is required to place deposit, which is locked for challenge period. To return deposit back to his balance he need to close the channel. Both operations burn Ether with transaction cost. Agent can also check blockchain event for uncooperative closes of channel made Client and rate him accordingly. This limits effectiveness of attack.

SUMMARY

Even this measures still don’t prevent 100% of such attacks, it definitely limits probability and effectiveness of them for both Clients and Agents.

Please join to our Masterminds group. Send any questions, thoughts and improvement suggestion to andrei@privatix.io or leave comment to this article