# Reconfigurable Smart Contracts for Renewable Energy Exchange with Re-Use of Verification Rules
## 6 The Pattern Implementation
### Smart Contract Reconfigurability  
The concrete _ExchangeEnergyContract_ class is marked with the _final_ keyword. As a result, no class can further inherit from the class. At the same time, marking the abstract class _SmartContract_ with the _sealed_ keyword secures the possibility of implementation only to those classes that are listed in the declaration of that class after the _permits_ keyword. In the constructor of the smart contract class, objects of all required verification rules, from the standard configuration, are instantiated and added to the array-backed list of rules. The _ExchangeEnergyContract_ class in the _checkSC(0)_ method validates conditions of specific verification rules in the list (Listing 10).  
When checking transactions to be executed, the smart contract reconfigures itself to the appropriate configuration of verification rules. The mechanism of polymorphism was used, and the _checkSC()_ method was overloaded. Depending on the transaction object type, the smart contract invokes the appropriate method and, if necessary, changes the verification rules on the list. Moreover, the current type of configuration is saved in the contract. Thanks to this, the rules in the list are changed only when the type of transaction being processed is changed.  
```
packagepl.gdynia.amw.scdp.contracts; importpl.gdynia.amw.scdp.Transaction; importpl.gdynia.amw.scdp.TransactionCross; importpl.gdynia.amw.scdp.rules.VerificationRule; importpl.gdynia.amw.scdp.rules.exchangeEnergy.*; importpl.gdynia.amw.scdp.rules.exchangeEnergy.crossCommunity.*; importjava.util.Arrays; publicfinalclassExchangeEnergyContractextendsSmartContract{ privatebooleanstandardConf; publicExchangeEnergyContract(){ standardConf=true; //populatesarray-backed listof-verificationrules rulesList=Arrays.asList((newTechnicalVR1(),newTechnicalVR2(),newBusinessVR1(),newBusinessVR2(),newExpandingVR1()); ] privatevoidpopulateRulesStandard(){ rulesList.set(0,newTechnicalVR1()); rulesList.set(4,newExpandingVR1()); ] privatevoidpopulateRulesExtended(){ rulesList.set(0,newTechnicalVR1 Extended()); rulesList.set(4,newExpandingVR1 Extended()); } @Override publicbooleancheckSC(Transactiontr){ if(!standardConf){ populateRulesStandard(); standardConf=true;} returncheck(tr); ] publicbooleancheckSC(TransactionCrosstr){ if(standardConf){ populateRulesExtended(); standardConf=false;} returncheck(tr); ] privatebooleancheck(Transactiontr){ booleancorrect=false; for(VerificationRulevR:rulesList){ correct=vR.runRule(tr); if(!correct)break; ] returncorrect; } ] }
```  
**Listing 10**: The source code of the ExchangeEnergyContract class.  
The annotation @_Override_ indicates a method that overrides a method declaration in a supertype. The annotation is used to mark _checkSC()_ method in _ExchangeEnergyContract_ class. The method iterates over the list of verification rules, where \(vR_{n}\) is the n-th rule in the list. Its execution can be described using the _Logical AND_ operator (&& in Java) as the expression (2):  
\[vR_{1}\wedge vR_{2}\wedge...\wedge vR_{n} \tag{2}\]  
Using the array-backed list ensures that the list of validation rules is of a fixed size. That closes the possibility of adding more rules. However, extending rules are introduced into the pattern. The mechanism may enable a controlled annexation of a smart contract. By default, the _runRule_() method of the extending verification rule returns a _true_ Boolean value.