Identify Breaking Changes in Casper Types and Contract API

[devendran-m]

To support the transition from version 1.5.8 to 2.0 of the Casper Types and Contract API, it is essential to identify any breaking changes in the APIs and ensure compatibility for existing smart contracts. This involves taking a representative sample of contracts from 1.5.8, compiling them against 2.0, and analysing any discrepancies or breaking changes in functionality or structure. The process must also verify the updated API's correctness and integration with existing contract logic.

Acceptance Criteria:
Breaking Changes Identification:

• Identify and document all breaking changes introduced in Casper Types 2.0 and Contract API.
• Provide detailed descriptions of changes (e.g., moved APIs, deprecated features, or modified data structures).

Integration Test Coverage:

• Identify the modifications/ new integration tests required to verify compatibility across protocol boundaries (1.5.8 to 2.0).
• Create a separate Integration Test Ticket to apply the changes and ensure integration tests cover common use cases and edge cases.

Documentation Updates:

• Identify the updates required to API documentation to reflect changes in Casper Types and Contract API.
• Create a separate Docs ticket to track the necessary updates for developers migrating contracts from 1.5.8 to 2.0.