CIP (Draft) :Extending Smart Contracts To Gain Some Functionality Present in ETH and Other Chains By Querying the Node

Abstract

This CIP seeks to add more functionality to the chain in a way that will prevent certain attacks by bad actors and be independent of the uptime of 3rd party solutions.

Motivation

The Cardano blockchain is designed on rigorous foundations and has become a superset of the count-based model. In theory, this would enable us to do much more than other chains, however, we have yet to realize this in practice.

Due to the early and developing state of the Cardano blockchain it is understandable that a lot of these functionalities would come later on, however, that means that right now I can do a lot of rather basic seeming things on chains like Ethereum that I can’t on Cardano.

This CIP is made to solve that problem. I am attempting to make some smart contracts that validate based upon user behavior. This is to make redundant Api services which are subject to man in the middle attacks.

The key here is that by having the blockchain serve as the source of truth we can prevent a number of potential attacks by bad actors such as altering the API feed and have the contract run independently of the uptime of solutions like blockfrost (which are known to crash occasional).

Specification

The reason I cannot use user behavior to be the activation I want for my contract is that there is no direct method for a Plutus smart contract to get data from the chain. It seems that this problem could be fixed by taking in a pubKeyHash and out putting some information of the corresponding address (like transaction history → this could be limited in scope like last outgoing transaction). This seems like its in the scope of possible updates to the chain as the chain both stores the data and validates smart contracts, so its reasonable to assume that at validation time it could get some data from itself.

If accepted as a CIP, I believe that the Plutus and node teams would have to sit down and jointly agree on the best possible trade-off to accept when building this behavior. As I have little background in creating compilers and the foundations of node interactions, I do not believe I should give any specification on how to implement this as it requires two teams of domain experts familiar with the Cardano blockchain to do so.

Examples of possible functions:

getLastTransaction :: pkh -> Tx
getFIrstTransacion :: pkh -> Tx
getLastOutgoing :: pkh -> Tx
getLastIncoming :: pkh -> Tx

1 Like