Automatically merged updates to draft EIP(s) 2746 (#2883)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-2746.md

@@ -16,7 +16,9 @@ An interface for using a smart contract as a rules engine.  A single deployed co
 This standard proposes an interface that will allow the creation of hierarchal sets of rules (i.e., RuleTrees) that can be invoked to evaluate and manipulate a registered data domain.  At the time of this draft, all intentions to insert additional functionality onto the blockchain requires the coding and creation of a newly deployed contract.  However, this standard will allow users to deploy a contract just once, one which will then allow them to create (and invoke) pipelines of commands within that contract.
 
 ## Motivation
-At the time of this draft, all development for Ethereum requires writing the code that forms smart contracts and then deploying those contracts to Ethereum.  This requirement pertains to all cases, even for simple cases of examining a value and/or altering it.  However, less technical companies and users might also want to configure and deploy simple functionality onto the chain, without knowing the reveleant languages or details necessary.  By having the data domain and the predefined actions implemented along with this interface, a deployed instance of such a contract can provide functionality to no-code or little-code clients, allowing more users of various technical proficiency to interact with the Ethereum ecosystem.
+At the time of this draft, all development for Ethereum requires writing the code that forms smart contracts and then deploying those contracts to Ethereum.  In order to create a proper contract, many considerations must be taken into account when designing and implementing the code, especially in terms of efficiency (i.e., gas cost) and security.  Even the simplest contracts require a certain amount of vigilance and examination, before and after deployment. These requirements pertain to all cases, even for simple cases of examining a value and/or altering it.
+
+These technical challenges might form an obstacle for many others who might wish to create software around Ethereum.  Less technical companies and users might also want to configure and deploy simple functionality onto the chain, without knowing the relevant languages or details necessary.  By having the data domain and the predefined actions (i.e., types of rules) implemented along with this interface, a deployed instance of such a rules engine contract can provide efficient and safe functionality to no-code or little-code clients, allowing more users of various technical proficiency to interact with the Ethereum ecosystem.
 
 ## Specification
 For the clarification of terminology, an Attribute is a registered data point within the data domain, representing data that exists either in the rules engine contract or elsewhere.  A Rule is an predefined action that occurs upon a single data point (i.e., Attribute) in the predefined data domain.  For example, a Rule could check whether the Attribute 'TokenAmt' has a value less than the RHL (i.e., right-hand value) of 10.   A RuleSet is a collection of Rules, where their collection invocation creates a boolean result that determines the navigational flow of execution between RuleSets.  A RuleTree is a collection of RuleSets that are organized within a hierarchy, where RuleSets can contain other RuleSets.