Getting Started with Stratis Blockchain Development Quest: Running Your First Stratis Node

Getting Started with Stratis Blockchain Development Quest: Running Your First Stratis Node

Getting Started with Stratis Blockchain Development: Running Your First Stratis Node

Stratis is a powerful and flexible blockchain development platform designed to enable businesses and developers to build, test, and deploy blockchain applications with ease. If you’re looking to start developing for the Stratis blockchain, the first crucial step is to run a Stratis node. This article will guide you through the process, providing a clear and concise roadmap to get your development journey underway.

Introduction to Stratis Blockchain

Stratis offers a blockchain-as-a-service (BaaS) platform, which simplifies the development, deployment, and maintenance of blockchain solutions. Built on a foundation of the C# programming language and the .NET framework, Stratis provides an accessible environment for developers familiar with these technologies. Key features of Stratis include smart contracts, sidechains, and full node capabilities, all designed to streamline blockchain development and integration.

Why Run a Stratis Node?

Running a Stratis node is essential for several reasons:

  • Network Participation: Nodes form the backbone of the blockchain network, validating and relaying transactions.
  • Development and Testing: A local node provides a controlled environment for testing and debugging blockchain applications.
  • Decentralization: By running a node, you contribute to the decentralization and security of the Stratis network.


Before setting up a Stratis node, ensure you have the following:

  • A computer with a modern operating system (Windows, macOS, or Linux).
  • .NET Core SDK installed.
  • Sufficient disk space (at least 10 GB) for the blockchain data.
  • A stable internet connection.

Step-by-Step Guide to Running a Stratis Node

1. Install .NET Core SDK

First, install the .NET Core SDK, which is necessary to run the Stratis Full Node. You can download it from the official .NET Core website. Follow the installation instructions for your specific operating system. I recommend having all DotNetCore SDKs because the source code for most of the Stratis solutions target really an old framework version like.NET Core 2.1 so it’s better to have multiple choices of framework in case you need to re-target for compatibility

.NET Core Versions

  • .NET Core 3.1 (LTS)
  • .NET Core 3.0
  • .NET Core 2.2
  • .NET Core 2.1 (LTS)
  • .NET Core 2.0
  • .NET Core 1.1
  • .NET Core 1.0

Installation Links

Download .NET Core SDKs

2. Clone the Stratis Full Node Repository

Next, clone the Stratis Full Node repository from GitHub. Open a terminal or command prompt and run the following command:

git clone

This command will download the latest version of the Stratis Full Node source code to your local machine.

3. Build the Stratis Full Node

Navigate to the directory where you cloned the repository:

cd StratisFullNode

Now, build the Stratis Full Node using the .NET Core SDK:

dotnet build

This command compiles the source code and prepares it for execution.

4. Run the Stratis Full Node

Once the build process is complete, you can start the Stratis Full Node. Use the following command to run the node:

cd Stratis.StraxD
dotnet run -testnet

This will initiate the Stratis node, which will start synchronizing with the Stratis blockchain network.

5. Verify Node Synchronization

After starting the node, you need to ensure it is synchronizing correctly with the network. You can check the node’s status by visiting the Stratis Full Node’s API endpoint in your web browser:


here is more information about the possible ports for the API depending on which network you want to use (test or main) and which command did you use to start up the API

To run the API in a specific port you can use the following code

StraxTest (dotnet run -testnet -apiport=38221)






You should see a JSON response indicating the node’s current status, including its synchronization progress.


Congratulations! You have successfully set up and run your first Stratis node. This node forms the foundation for your development activities on the Stratis blockchain. With your node up and running, you can now explore the various features and capabilities of the Stratis platform, including deploying smart contracts, interacting with sidechains, and building blockchain applications.

As you continue your journey, remember that the Stratis community and its comprehensive documentation are valuable resources. Engage with other developers, seek guidance, and contribute to the growing ecosystem of Stratis-based solutions. Happy coding!


Previous articles

Discovering the Simplicity of C# in Blockchain Development with Stratis | Joche Ojeda


Choosing the Right JSON Serializer for SyncFramework

Choosing the Right JSON Serializer for SyncFramework: DataContractJsonSerializer vs Newtonsoft.Json vs System.Text.Json

When building robust and efficient synchronization solutions with SyncFramework, selecting the appropriate JSON serializer is crucial. Serialization directly impacts performance, data integrity, and compatibility, making it essential to understand the differences between the available options: DataContractJsonSerializer, Newtonsoft.Json, and System.Text.Json. This post will guide you through the decision-making process, highlighting key considerations and the implications of using each serializer within the SyncFramework context.

Understanding SyncFramework and Serialization

SyncFramework is designed to synchronize data across various data stores, devices, and applications. Efficient serialization ensures that data is accurately and quickly transmitted between these components. The choice of serializer affects not only performance but also the complexity of the implementation and maintenance of your synchronization logic.


DataContractJsonSerializer is tightly coupled with the DataContract and DataMember attributes, making it a reliable choice for scenarios that require explicit control over serialization:

  • Strict Type Adherence: By enforcing strict adherence to data contracts, DataContractJsonSerializer ensures that serialized data conforms to predefined types. This is particularly important in SyncFramework when dealing with complex and strongly-typed data models.
  • Data Integrity: The explicit nature of DataContract and DataMember attributes guarantees that only the intended data members are serialized, reducing the risk of data inconsistencies during synchronization.
  • Compatibility with WCF: If SyncFramework is used in conjunction with WCF services, DataContractJsonSerializer provides seamless integration, ensuring consistent serialization across services.

When to Use: Opt for DataContractJsonSerializer when working with strongly-typed data models and when strict type fidelity is essential for your synchronization logic.

Newtonsoft.Json (Json.NET)

Newtonsoft.Json is known for its flexibility and ease of use, making it a popular choice for many .NET applications:

  • Ease of Integration: Newtonsoft.Json requires no special attributes on classes, allowing for quick integration with existing codebases. This flexibility can significantly speed up development within SyncFramework.
  • Advanced Customization: It offers extensive customization options through attributes like JsonProperty and JsonIgnore, and supports complex scenarios with custom converters. This makes it easier to handle diverse data structures and serialization requirements.
  • Wide Adoption: As a widely-used library, Newtonsoft.Json benefits from a large community and comprehensive documentation, providing valuable resources during implementation.

When to Use: Choose Newtonsoft.Json for its flexibility and ease of use, especially when working with existing codebases or when advanced customization of the serialization process is required.


System.Text.Json is a high-performance JSON serializer introduced in .NET Core 3.0 and .NET 5, providing a modern and efficient alternative:

  • High Performance: System.Text.Json is optimized for performance, making it suitable for high-throughput synchronization scenarios in SyncFramework. Its minimal overhead and efficient memory usage can significantly improve synchronization speed.
  • Integration with ASP.NET Core: As the default JSON serializer for ASP.NET Core, System.Text.Json offers seamless integration with modern .NET applications, ensuring consistency and reducing setup time.
  • Attribute-Based Customization: While offering fewer customization options compared to Newtonsoft.Json, it still supports essential attributes like JsonPropertyName and JsonIgnore, providing a balance between performance and configurability.

When to Use: System.Text.Json is ideal for new applications targeting .NET Core or .NET 5+, where performance is a critical concern and advanced customization is not a primary requirement.

Handling DataContract Requirements

In SyncFramework, certain types may require specific serialization behaviors dictated by DataContract notations. When using Newtonsoft.Json or System.Text.Json, additional steps are necessary to accommodate these requirements:

  • Newtonsoft.Json: Use attributes such as JsonProperty to map JSON properties to DataContract members. Custom converters may be needed for complex serialization scenarios.
  • System.Text.Json: Employ JsonPropertyName and custom converters to align with DataContract requirements. While less flexible than Newtonsoft.Json, it can still handle most common scenarios with appropriate configuration.


Choosing the right JSON serializer for SyncFramework depends on the specific needs of your synchronization logic. DataContractJsonSerializer is suited for scenarios demanding strict type fidelity and integration with WCF services. Newtonsoft.Json offers unparalleled flexibility and ease of integration, making it ideal for diverse and complex data structures. System.Text.Json provides a high-performance, modern alternative for new .NET applications, balancing performance with essential customization.

By understanding the strengths and limitations of each serializer, you can make an informed decision that ensures efficient, reliable, and maintainable synchronization in your SyncFramework implementation.

How ARM, x86, and Itanium Architectures Affect .NET Developers

How ARM, x86, and Itanium Architectures Affect .NET Developers

The ARM, x86, and Itanium CPU architectures each have unique characteristics that impact .NET developers. Understanding how these architectures affect your code, along with the importance of using appropriate NuGet packages, is crucial for developing efficient and compatible applications.

ARM Architecture and .NET Development

1. Performance and Optimization:

  • Energy Efficiency: ARM processors are known for their power efficiency, benefiting .NET applications on devices like mobile phones and tablets with longer battery life and reduced thermal output.
  • Performance: ARM processors may exhibit different performance characteristics compared to x86 processors. Developers need to optimize their code to ensure efficient execution on ARM architecture.

2. Cross-Platform Development:

  • .NET Core and .NET 5+: These versions support cross-platform development, allowing code to run on Windows, macOS, and Linux, including ARM-based versions.
  • Compatibility: Ensuring .NET applications are compatible with ARM devices may require testing and modifications to address architecture-specific issues.

3. Tooling and Development Environment:

  • Visual Studio and Visual Studio Code: Both provide support for ARM development, though there may be differences in features and performance compared to x86 environments.
  • Emulators and Physical Devices: Testing on actual ARM hardware or using emulators helps identify performance bottlenecks and compatibility issues.

x86 Architecture and .NET Development

1. Performance and Optimization:

  • Processing Power: x86 processors are known for high performance and are widely used in desktops, servers, and high-end gaming.
  • Instruction Set Complexity: The complex instruction set of x86 (CISC) allows for efficient execution of certain tasks, which can differ from ARM’s RISC approach.

2. Compatibility:

  • Legacy Applications: x86’s extensive history means many enterprise and legacy applications are optimized for this architecture.
  • NuGet Packages: Ensuring that NuGet packages target x86 or are architecture-agnostic is crucial for maintaining compatibility and performance.

3. Development Tools:

  • Comprehensive Support: x86 development benefits from mature tools and extensive resources available in Visual Studio and other IDEs.

Itanium Architecture and .NET Development

1. Performance and Optimization:

  • High-End Computing: Itanium processors were designed for high-end computing tasks, such as large-scale data processing and enterprise servers.
  • EPIC Architecture: Itanium uses Explicitly Parallel Instruction Computing (EPIC), which requires different optimization strategies compared to x86 and ARM.

2. Limited Support:

  • Niche Market: Itanium has a smaller market presence, primarily in enterprise environments.
  • .NET Support: .NET support for Itanium is limited, requiring careful consideration of architecture-specific issues.

CPU Architecture and Code Impact

1. Instruction Sets and Performance:

  • Differences: x86 (CISC), ARM (RISC), and Itanium (EPIC) have different instruction sets, affecting code efficiency. Optimizations effective on one architecture might not work well on another.
  • Compiler Optimizations: .NET compilers optimize code for specific architectures, but understanding the underlying architecture helps write more efficient code.

2. Multi-Platform Development:

    • Conditional Compilation: .NET supports conditional compilation for architecture-specific code optimizations.

    #if ARM
    // ARM-specific code
    #elif x86
    // x86-specific code
    #elif Itanium
    // Itanium-specific code
  • Libraries and Dependencies: Ensure all libraries and dependencies in your .NET project are compatible with the target CPU architecture. Use NuGet packages that are either architecture-agnostic or specifically target your architecture.

3. Debugging and Testing:

  • Architecture-Specific Bugs: Bugs may manifest differently across ARM, x86, and Itanium. Rigorous testing on all target architectures is essential.
  • Performance Testing: Conduct performance testing on each architecture to identify and resolve any specific issues.

Supported CPU Architectures in .NET

1. .NET Core and .NET 5+:

  • x86 and x64: Full support for 32-bit and 64-bit x86 architectures across all major operating systems.
  • ARM32 and ARM64: Support for 32-bit and 64-bit ARM architectures, including Windows on ARM, Linux on ARM, and macOS on ARM (Apple Silicon).
  • Itanium: Limited support, mainly in specific enterprise scenarios.

2. .NET Framework:

  • x86 and x64: Primarily designed for Windows, the .NET Framework supports both 32-bit and 64-bit x86 architectures.
  • Limited ARM and Itanium Support: The traditional .NET Framework has limited support for ARM and Itanium, mainly for older devices and specific enterprise applications.

3. .NET MAUI and Xamarin:

  • Mobile Development: .NET MAUI (Multi-platform App UI) and Xamarin provide extensive support for ARM architectures, targeting Android and iOS devices which predominantly use ARM processors.

Using NuGet Packages

1. Architecture-Agnostic Packages:

  • Compatibility: Use NuGet packages that are agnostic to CPU architecture whenever possible. These packages are designed to work across different architectures without modification.
  • Example: Common libraries like Newtonsoft.Json, which work across ARM, x86, and Itanium.

2. Architecture-Specific Packages:

  • Performance: For performance-critical applications, use NuGet packages optimized for the target architecture.
  • Example: Graphics processing libraries optimized for x86 may need alternatives for ARM or Itanium.


For .NET developers, understanding the impact of ARM, x86, and Itanium architectures is essential for creating efficient, cross-platform applications. The differences in CPU architectures affect performance, compatibility, and optimization strategies. By leveraging cross-platform capabilities of .NET, using appropriate NuGet packages, and testing thoroughly on all target architectures, developers can ensure their applications run smoothly across ARM, x86, and Itanium devices.

Understanding AppDomains in .NET Framework and .NET 5 to 8

Understanding AppDomains in .NET Framework and .NET 5 to 8

Understanding AppDomains in .NET Framework and .NET 5 to 8

AppDomains, or Application Domains, have been a fundamental part of isolation and security in the .NET Framework, allowing multiple applications to run under a single process without affecting each other. However, the introduction of .NET Core and its evolution through .NET 5 to 8 has brought significant changes to how isolation and application boundaries are handled. This article will explore the concept of AppDomains in the .NET Framework, their transition and replacement in .NET 5 to 8, and provide code examples to illustrate these differences.

AppDomains in .NET Framework

In the .NET Framework, AppDomains served as an isolation boundary for applications, providing a secure and stable environment for code execution. They enabled developers to load and unload assemblies without affecting the entire application, facilitating application updates, and minimizing downtime.

Creating an AppDomain

using System;

namespace NetFrameworkAppDomains
    class Program
        static void Main(string[] args)
            // Create a new application domain
            AppDomain newDomain = AppDomain.CreateDomain("NewAppDomain");

            // Load an assembly into the application domain

            // Unload the application domain

AppDomains in .NET 5 to 8

With the shift to .NET Core and its successors, the concept of AppDomains was deprecated, reflecting the platform’s move towards cross-platform compatibility and microservices architecture. Instead of AppDomains, .NET 5 to 8 emphasizes on assembly loading contexts for isolation and the use of containers (like Docker) for application separation.

AssemblyLoadContext in .NET 5 to 8

using System;
using System.Reflection;
using System.Runtime.Loader;

namespace NetCoreAssemblyLoading
    class Program
        static void Main(string[] args)
            // Create a new AssemblyLoadContext
            var loadContext = new AssemblyLoadContext("MyLoadContext", true);

            // Load an assembly into the context
            Assembly assembly = loadContext.LoadFromAssemblyPath("MyAssembly.dll");

            // Execute a method from the assembly (example method)
            MethodInfo methodInfo = assembly.GetType("MyNamespace.MyClass").GetMethod("MyMethod");
            methodInfo.Invoke(null, null);

            // Unload the AssemblyLoadContext

Differences and Considerations

  • Isolation Level: AppDomains provided process-level isolation without needing multiple processes. In contrast, AssemblyLoadContext provides a lighter-weight mechanism for loading assemblies but doesn’t offer the same isolation level. For higher isolation, .NET 5 to 8 applications are encouraged to use containers or separate processes.
  • Compatibility: AppDomains are specific to the .NET Framework and are not supported in .NET Core and its successors. Applications migrating to .NET 5 to 8 need to adapt their architecture to use AssemblyLoadContext or explore alternative isolation mechanisms like containers.
  • Performance: The move away from AppDomains to more granular assembly loading and containers reflects a shift towards microservices and cloud-native applications, where performance, scalability, and cross-platform compatibility are prioritized.


While the transition from AppDomains to AssemblyLoadContext and container-based isolation marks a significant shift in application architecture, it aligns with the modern development practices and requirements of .NET applications. Understanding these differences is crucial for developers migrating from the .NET Framework to .NET 5 to

Introduction to Machine Learning in C#: Spam Detection using Binary Classification

Introduction to Machine Learning in C#: Spam Detection using Binary Classification

Introduction to Machine Learning in C#: Spam using Binary Classification

This example demonstrates the basics of machine learning in C# using ML.NET, Microsoft’s machine learning framework specifically designed for .NET applications. ML.NET offers a versatile, cross-platform framework that simplifies integrating machine learning into .NET applications, making it accessible for developers familiar with the .NET ecosystem.

Technologies Used

  • C#: A modern, object-oriented programming language developed by Microsoft, which is widely used for a variety of applications. In this example, C# is used to define data models, process data, and implement the machine learning pipeline.
  • ML.NET: An open-source and cross-platform machine learning framework for .NET. It is used in this example to create a machine learning model for classifying emails as spam or not spam. ML.NET simplifies the process of training, evaluating, and consuming machine learning models in .NET applications.
  • .NET Core: A cross-platform version of .NET for building applications that run on Windows, Linux, and macOS. It provides the runtime environment for our C# application.

The example focuses on a simple spam detection system. It utilizes text data processing and binary classification, two common tasks in machine learning, to classify emails into spam and non-spam categories. This is achieved through the use of a logistic regression model, a fundamental algorithm for binary classification problems.

Creating an NUnit Test Project in Visual Studio Code


           Setting up NUnit for DecisionTreeDemo


    • Install .NET Core SDK

      Download and install the .NET Core SDK from the .NET official website.

    • Install Visual Studio Code

      Download and install Visual Studio Code (VS Code) from here. Also, install the C# extension for VS Code by Microsoft.

    • Create a New .NET Core Project

      Open VS Code, and in the terminal, create a new .NET Core project:

      dotnet new console -n DecisionTreeDemo
      cd DecisionTreeDemo
    • Add the ML.NET Package

      Add the ML.NET package to your project:

      dotnet add package Microsoft.ML
    • Create the Test Project

      Create a separate directory for your test project, then initialize a new test project:

      mkdir DecisionTreeDemo.Tests
      cd DecisionTreeDemo.Tests
      dotnet new nunit
    • Add Required Packages to Test Project

      Add the necessary NUnit and ML.NET packages:

      dotnet add package NUnit
      dotnet add package Microsoft.NET.Test.Sdk
      dotnet add package NUnit3TestAdapter
      dotnet add package Microsoft.ML
    • Reference the Main Project

      Reference the main project:

          dotnet add reference ../DecisionTreeDemo/DecisionTreeDemo.csproj
    • Write Test Cases

      Write NUnit test cases within your test project to test different functionalities of your ML.NET application.

      Define the Data Model for the Email

      Include the content of the email and whether it’s classified as spam.

      public class Email
          public string Content { get; set; }
          [LoadColumn(1), ColumnName("Label")]
          public bool IsSpam { get; set; }

      Define the Model for Spam Prediction

      This model is used to determine whether an email is spam.

      public class SpamPrediction
          public bool IsSpam { get; set; }

      Write the test case

      // Create a new ML context for the application, which is a starting point for ML.NET operations.
              var mlContext = new MLContext();
              // Example dataset of emails. In a real-world scenario, this would be much larger and possibly loaded from an external source.
              var data = new List
                  new Email { Content = "Buy cheap products now", IsSpam = true },
                  new Email { Content = "Meeting at 3 PM", IsSpam = false },
                  // Additional data can be added here...
              // Load the data into the ML.NET data model.
              var trainData = mlContext.Data.LoadFromEnumerable(data);
              // Define the data processing pipeline. Here we are featurizing the text (i.e., converting text into numeric features) and then     applying a logistic regression model.
              var pipeline = mlContext.Transforms.Text.FeaturizeText("Features", nameof(Email.Content))
              // Train the model on the loaded data.
              var model = pipeline.Fit(trainData);
              // Create a prediction engine for making predictions on individual data samples.
              var predictionEngine = mlContext.Model.CreatePredictionEngine<Email, SpamPrediction>(model);
              // Create a sample email to test the model.
              var sampleEmail = new Email { Content = "Special discount, buy now!" };
              var prediction = predictionEngine.Predict(sampleEmail);
              // Output the prediction to the console.
              Debug.WriteLine($"Email: '{sampleEmail.Content}' is {(prediction.IsSpam ? "spam" : "not spam")}");
    • Running Tests

      Run the tests with the following command:

      dotnet test

As you can see the test will pass because the sample email contains the word “buy” that was used in the training data and was labeled as spam

You can download the source code for this article here

This article has explored the fundamentals of machine learning in C# using the ML.NET framework. By defining specific data models and utilizing ML.NET’s powerful features, we demonstrated how to build a simple yet effective spam detection system. This example serves as a gateway into the vast world of machine learning, showcasing the potential for integrating AI technologies into .NET applications. The skills and concepts learned here lay the groundwork for further exploration and development in the exciting field of machine learning and artificial intelligence.