Migrated text from defunct early CIP.

Author: bwbush

CIP/README.md

@@ -21,14 +21,44 @@ License: Apache-2.0
 >
 > A short (\~200 word) description of the proposed solution and the technical issue being addressed.
 
+As Cardano evolves, there will be increasing demand for greater network  
+capacity to support new and existing users and applications. The long term  
+solution is to rebase Cardano on the new Ouroboros Leios protocol.  
+Ouroboros Leios is a new member of the Ouroboros family that is designed  
+specifically for high throughput, without compromising security. This will  
+meet expected future demands, providing a basis for continuing Cardano growth  
+and scalability.
 
 ## Motivation: why is this CIP necessary?
 
 > [!NOTE]
 > 
 > A clear explanation that introduces a proposal's purpose, use cases, and stakeholders. If the CIP changes an established design, it must outline design issues that motivate a rework. For complex proposals, authors must write a [Cardano Problem Statement (CPS) as defined in CIP-9999][CPS] and link to it as the `Motivation`.
 
-
+Cardano's current throughput (measured both in data rate and available script  
+execution time) is adequate for the current demand. There is also some  
+opportunity to increase the block sizes and script execution limits to meet  
+emerging future demands for increased network capacity. There are however  
+fundamental limits to how far the block size and the script execution budget  
+can be pushed, while maintaining system security.
+
+Under Ouroboros Praos, in order to ensure the security of the overall system,  
+blocks must be distributed across the network reliably in "" time slots.  
+This is set to be 5 seconds on the Cardano mainnet. The block relaying process  
+is an essentially serial process: blocks must be relayed between consecutive  
+block producer nodes through a series of intermediate relay nodes. The overall  
+time that this takes is proportional to the number of network hops between one  
+block producer and the next, and the network latency of each of those hops  
+(which must in general span the whole globe). Given that this must always  
+happen within 5 seconds, this puts a hard upper limit on how large each block  
+can be and also on how much time can be spent validating transactions and  
+scripts.
+
+In order to substantially scale beyond this requires changes to the underlying  
+blockchain algorithm. There are significant opportunities to scale: the  
+network and CPU resources on most nodes are almost idle much of the time. With  
+a different algorithm, these resources can be used to increase the total chain  
+bandwidth.
 ## Specification
 
 > [!NOTE]