73 research outputs found
Artemis Accords and Resource Mining in Outer Space
No full textThis book explores the timely intersection of international law, space exploration, and global equity, focusing on the implications of the Artemis Accords. As humanity embarks on a new era of space exploration, driven by technological advancements and geopolitical competition, the Artemis Accords represent a pivotal milestone in shaping the legal frameworks for outer space activities. These non-binding agreements, established by NASA and the U.S. Department of State, facilitate international cooperation in civil exploration and the peaceful use of the Moon, Mars, and other celestial bodies. The Accords outline a structure for resource mining on the Moon while emphasizing peaceful exploration. However, they also raise questions about governance, ownership, and accountability, particularly regarding private enterprises and international competition.
The book critically examines the potential for space resource mining to perpetuate global inequities, drawing parallels with historical patterns of colonialism. It emphasizes the need for more equitable frameworks that allow nations, including those from the Global South, to benefit from space exploration. The contributors, experts in space law and policy, provide diverse perspectives on the challenges and opportunities of resource mining in outer space, addressing ethical and environmental considerations to promote sustainability. Through case studies and analysis, the book offers innovative solutions for ensuring a just and inclusive future for space exploration, making it an essential resource for legal scholars, policymakers, and anyone interested in space law and global equity
Artemis Accords as Evolutive Law-Making: Lunar Space Mining and the Rise of Space Militarisation
No full textThe new age of technological developments continues to bring humanity much closer to Moon surface mining. Tapping the lunar economy could provide humanity with the potential to expand its presence on the Moon, as well as further into the solar system. In this context, the Artemis Accords and the geopolitics around it are shaping new complexities of lunar resource extraction. While exploiting the lunar economy is the primary objective of the Artemis Accords, the non-binding principles apply to civil activities in outer space, and all activities that may take place on the Moon, Mars, comets, and asteroids, including their surfaces and subsurfaces, as well as in orbit of the Moon or Mars, in the Lagrangian points for the Earth-Moon system, and in transit between these celestial bodies and locations. The United States drafted the Accords is building consensus, and as of January 2025, the number of signatories has grown to 53. The Artemis Accords express a soft obligation to ‘reinforce and implement the Outer Space Treaty, the Registration Convention, the Agreement on the Rescue and Return of Astronauts’ and ‘other norms of behaviour that NASA and its partners have supported’. However, some of the principles raise concerns about its consistencies with the fundamentals of space law as it introduce concepts such as safety zones, resource extraction and use and interoperability. It creates new challenges that raise questions about sovereignty, commercial rights, sustainability in space and potential military use of the lunar environment, as nations may leverage lunar activities for strategic dominance. This chapter explores the Artemis Accords as a new form of evolutive lawmaking redesigning global space governance through unipolarism masquerading as multilateralism. The chapter primarily focuses on how the Accords can foster competitive dynamics among spacefaring nations, which may accelerate the development of dual-use technologies under the facade of peaceful exploration. By placing the Accords within the broader context of astropolitical diplomacy, this chapter explores the future of lunar space mining and how the Accords will shape the future norms of militarisation and commercial exploitation of the lunar environment
Evaluating Compliance with International Standards and Best Practices at the Mumbai Airport
No full textChhatrapati Shivaji Maharaj International Airport (CSMIA), ranked 28th in the world and 14th in Asia in the fiscal year 2022 in terms of passenger traffic is one of the busiest airports located in the financial capital of India. It is the second busiest airport in India after Delhi. With the privatisation of Mumbai’s CSMIA, the Indian airport industry saw a dramatic transformation in 2006. With the expansion of the new terminal, the economic value that the airport will hold in terms of trickling down economic benefits to the city and the financial growth opportunities will be immense. The International Civil Aviation Organisation (ICAO) has created a thorough set of Standards and Recommended Practices (SARPs) for airports in its Annex 14 to the Chicago Convention in order to guarantee the security, regularity, and effectiveness of international air navigation. The chapter attempts to provide an overview of ‘International Standards’ and ‘Best Practices’ at the CSMIA, specifically in the areas of ‘Security Regulations’, ‘Passenger Service’ and ‘Sustainability’. The chapter evaluates Mumbai Airport’s adherence to ICAO and IATA security protocols, including passenger screening, access controls, and threat detection. The second part of the chapter will focus on airport management along with global benchmarks for efficient processing, amenities, and overall traveller experience. The third part of the chapter delves into the initiatives to minimize environmental impact, optimize resource usage, and promote green operations. To achieve global net zero targets, the Mumbai airport will play a key role in accelerating renewable energy adoption, optimising resource consumption, and driving circular economy initiatives. The chapter is the outcome of an in-depth review of processes, and performance data against global benchmarks, feedback from airport management, airlines, regulatory authorities, and a first-hand assessment of operations, infrastructure, and passenger experience. The chapter also explores the issues associated with customs, human rights violations and the curious case of illegal wildlife trafficking that happens at the Mumbai Airport. The chapter provides a detailed understanding of Mumbai Airport’s performance and compliance with global best practices. The chapter will also guide the airport’s efforts to enhance security, passenger services, and sustainability and suggest mechanisms to promote coordination with regulatory authorities for the successful implementation of the improvement initiatives
Delphi: Efficient Asynchronous Approximate Agreement for Distributed Oracles
No full text<h1>Delphi: Asynchronous Approximate Agreement for Distributed Oracles</h1>
<div>This repository contains a Rust implementation of the following distributed oracle agreement protocols.</div>
<div> </div>
<div>1. Delphi AAA protocol</div>
<div>2. FIN ACS protocol [1]</div>
<div>3. Abraham et al. AAA protocol [2]</div>
<div> </div>
<div>The repository uses the libchatter networking library available [here](https://github.com/libdist-rs/libchatter-rs). This code has been written as a research prototype and has not been vetted for security. Therefore, this repository can contain serious security vulnerabilities. Please use at your own risk.</div>
<div> </div>
<div>Please consider citing our paper if you use this artifact.</div>
<blockquote>
<div>Delphi: Efficient Asynchronous Approximate Agreement for Distributed Oracles</div>
<div>Akhil Bandarupalli, Adithya Bhat, Saurabh Bagchi, Aniket Kate, Chen-Da Liu-Zhang, and Michael K. Reiter</div>
<div>To appear at 54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2024.</div>
</blockquote>
<div> </div>
<h2>Dataset</h2>
<div>The repository also contains a dataset containing values of prominent cryptocurrencies polled from 12 cryptocurrency exchanges. Details are available in the `dataset` folder.</div>
<div> </div>
<h1>Quick Start</h1>
<div>We describe the steps to run this artifact.</div>
<h2>Hardware and OS setup</h2>
<div>1. This artifact has been run and tested on `x86_64` and `x64` architectures. However, we are unaware of any issues that would prevent this artifact from running on `x86` architectures.</div>
<p> </p>
<div>2. This artifact has been run and tested on Ubuntu `20.04.5 LTS` OS and Raspbian Linux version released on `2023-02-21`, both of which follow the Debian distro. However, we are unaware of any issues that would prevent this artifact from running on Fedora distros like CentOS and Red Hat Linux.</div>
<p> </p>
<h2>Rust installation and Cargo setup</h2>
<div>The repository uses the `Cargo` build tool. The compatibility between dependencies has been tested for Rust version `1.63`.</div>
<div> </div>
<div>3. Run the set of following commands to install the toolchain required to compile code written in Rust and create binary executable files.</div>
<div> </div>
<div><code> sudo apt-get update</code></div>
<div><code> sudo apt-get -y upgrade</code></div>
<div><code> sudo apt-get -y autoremove</code></div>
<div><code> sudo apt-get -y install build-essential</code></div>
<div><code> sudo apt-get -y install cmake</code></div>
<div><code> sudo apt-get -y install curl</code></div>
<div><code># Install rust (non-interactive)</code></div>
<div><code> curl --proto "=https" --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y</code></div>
<div><code> source HOME/.cargo/env</code></div>
<div><code> rustup install 1.63.0</code></div>
<div><code> rustup override set 1.63.0</code></div>
<div> </div>
<div>4. Build the repository using the following command. The command should be run in the directory containing the `Cargo.toml` file.</div>
<div> </div>
<div><code> cargo build --release</code></div>
<div><code> mkdir logs</code></div>
<div> </div>
<p> </p>
<div>5. Next, generate configuration files for nodes in the system using the following command. Make sure to create the directory (in this example, `testdata/hyb_4/`) before running this command.</div>
<div> </div>
<div><code> ./target/release/genconfig --base_port 8500 --client_base_port 7000 --client_run_port 9000 --NumNodes 4 --blocksize 100 --delay 100 --target testdata/hyb_4/ --local true</code></div>
<p> </p>
<div>6. After generating the configuration files, run the script `appxcon-test.sh` in the scripts folder with the following command line arguments. This command starts Delphi with four nodes.</div>
<div> </div>
<div><code> ./scripts/appxcon-test.sh {epsilon} {rho} {Delta} testdata/hyb_4/syncer</code></div>
<div> </div>
<div>7. Substitute desired values of \epsilon,\rho_0,\Delta\epsilon=1,\rho_0=10,\Delta=100000v_i to each node. This logic can be changed to make nodes start with custom input values.</div>
<div> </div>
<div>8. The outputs are logged into the `syncer.log` file in logs directory. The outputs of each node are printed in a JSON format, along with the amount of time the node took to terminate the protocol.</div>
<div> </div>
<div>9. Running the FIN ACS protocol requires additional configuration. FIN uses BLS threshold signatures to generate common coins necessary for proposal election and Binary Byzantine Agreement. This setup includes a master public key in the `pub` file, nnn=16,64,112,160 in the benchmark folder, in zip files `tkeys-{n}.tar.gz`. After generating these files, place them in the configuration directory (`testdata/hyb_4` in this example) and run the following command (We already performed this step and have these files ready in `testdata/hyb_4` folder).</div>
<div> </div>
<div><code># Kill previous processes running on these ports</code></div>
<div><code> sudo lsof -ti:7000-7015 | xargs kill -9</code></div>
<div><code> ./scripts/fin-test.sh testdata/hyb_4/syncer</code></div>
<div> </div>
<p> </p>
<div>10. Similarly, Abraham et al.'s Approximate Agreement protocol can be run using the following command.</div>
<div> </div>
<div><code># Kill previous processes running on these ports</code></div>
<div><code> sudo lsof -ti:7000-7015 | xargs kill -9</code></div>
<div><code> ./scripts/abraham-test.sh {epsilon} {delta} {Delta} testdata/hyb_4/syncer</code></div>
<div> </div>
<div>The parameters {epsilon} and {delta} must be equal in this context to yield Abraham et al.'s protocol. {Delta} must be set to be equal to the difference between honest inputs `M-m`. Example configuration run includes the following command.</div>
<div> </div>
<div><code> ./scripts/abraham-test.sh 2 2 20 testdata/hyb_4/syncer</code></div>
<div> </div>
<p> </p>
<h2>Running in AWS</h2>
<div>We utilize the code in the [Narwhal](https://github.com/MystenLabs/sui/tree/main/narwhal/benchmark) repository to execute code in AWS. This repository uses `fabric` to spawn AWS instances, install Rust, and build the repository on individual machines. Please refer to the `benchmark` directory for more instructions.</div>
<p> </p>
<h1>System architecture</h1>
<div>Each node runs as an independent process, which communicates with other nodes through sockets. Apart from the nodes running the protocol, the system also spawns a process called `syncer`. The `syncer` is responsible for measuring latency of completion. It reliably measures the system's latency by issuing `START` and `STOP` commands to all nodes. The nodes begin executing the protocol only after the `syncer` verifies that all nodes are online, and issues the `START` command by sending a message to all nodes. Further, the nodes send a `TERMINATED` message to the `syncer` once they terminate the protocol. The `syncer` records both start and termination times of all processes, which allows it to accurately measure the latency of each protocol.</div>
<p> </p>
<h1>Dependencies</h1>
<div>The artifact uses multiple Rust libraries for various functionalities. We give a list of all dependencies used by the artifact in the `Cargo.lock` file. `Cargo` automatically manages these dependencies and fetches the specified versions from the `crates.io` repository manager.</div>
<p> </p>
<h1>Code Organization</h1>
<div>The artifact is organized into the following modules of code.</div>
<div>1. The `config` directory contains code pertaining to configuring each node in the distributed system. Each node requires information about port to use, network addresses of other nodes, symmetric keys to establish pairwise authenticated channels between nodes, and protocol specific configuration parameters like values of . Code related to managing and parsing these parameters is in the `config` directory. This library has been borrowed from the `libchatter` (https://github.com/libdist-rs/libchatter-rs) repository.</div>
<p> </p>
<div>2. The `crypto` directory contains code that manages the pairwise authenticated channels between nodes. Mainly, nodes use Message Authentication Codes (MACs) for message authentication. This repo manages the required secret keys and mechanisms for generating MACs. This library has been borrowed from the `libchatter` (https://github.com/libdist-rs/libchatter-rs) repository.</div>
<p> </p>
<div>3. The `crypto_blstrs` directory contains code that enables nodes to toss common coins from BLS threshold signatures. This library has been borrowed from the `apss` (https://github.com/ISTA-SPiDerS/apss) repository.</div>
<p> </p>
<div>4. The `types` directory governs the message serialization and deserialization. Each message sent between nodes is serialized into bytecode to be sent over the network. Upon receiving a message, each node deserializes the received bytecode into the required message type after receiving. This library has been written on top of the library from `libchatter` (https://github.com/libdist-rs/libchatter-rs) repository.</div>
<p> </p>
<div>5. *Networking*: This repository uses the `libnet-rs` (https://github.com/libdist-rs/libnet-rs) networking library. Similar libraries include networking library from the `narwhal` (https://github.com/MystenLabs/sui/tree/main/narwhal/) repository. The nodes use the `tcp` protocol to send messages to each other.</div>
<p> </p>
<div>6. The `tools` directory consists of code that generates configuration files for nodes. This library has been borrowed from the `libchatter` (https://github.com/libdist-rs/libchatter-rs) repository.</div>
<p> </p>
<div>7. The `consensus` directory contains the implementations of various protocols. Primarily, it contains implementations of Abraham et al.'s approximate agreement protocol in the `hyb_appxcon` subdirectory, `delphi` protocol in the `delphi` subdirectory, and FIN protocol in `fin` subdirectory. Each protocol contains a `context.rs` file, which contains a function named `spawn` from where the protocol's execution starts. This function is called by the `node` library in the `node` folder. This library contains a `main.rs` file, which spawns an instance of a node running the respective protocol by invoking the `spawn` function.</div>
<p> </p>
<h1>References</h1>
<blockquote>
<div>[1] Duan, Sisi, Xin Wang, and Haibin Zhang. "Fin: Practical signature-free asynchronous common subset in constant time." In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, pp. 815-829. 2023.</div>
<div> </div>
<div>[2] Abraham, Ittai, Yonatan Amit, and Danny Dolev. "Optimal resilience asynchronous approximate agreement." In Principles of Distributed Systems: 8th International Conference, OPODIS 2004, Grenoble, France, December 15-17, 2004, Revised Selected Papers 8, pp. 229-239. Springer Berlin Heidelberg, 2005.</div>
</blockquote>
Delphi: Efficient Asynchronous Approximate Agreement for Distributed Oracles
No full text<h1>Delphi: Asynchronous Approximate Agreement for Distributed Oracles</h1>
<div>This repository contains a Rust implementation of the following distributed oracle agreement protocols.</div>
<div> </div>
<div>1. Delphi AAA protocol</div>
<div>2. FIN ACS protocol [1]</div>
<div>3. Abraham et al. AAA protocol [2]</div>
<div> </div>
<div>The repository uses the libchatter networking library available [here](https://github.com/libdist-rs/libchatter-rs). This code has been written as a research prototype and has not been vetted for security. Therefore, this repository can contain serious security vulnerabilities. Please use at your own risk.</div>
<div> </div>
<div>Please consider citing our paper if you use this artifact.</div>
<blockquote>
<div>Delphi: Efficient Asynchronous Approximate Agreement for Distributed Oracles</div>
<div>Akhil Bandarupalli, Adithya Bhat, Saurabh Bagchi, Aniket Kate, Chen-Da Liu-Zhang, and Michael K. Reiter</div>
<div>To appear at 54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2024.</div>
</blockquote>
<div> </div>
<h2>Dataset</h2>
<div>The repository also contains a dataset containing values of prominent cryptocurrencies polled from 12 cryptocurrency exchanges. Details are available in the `dataset` folder.</div>
<div> </div>
<h1>Quick Start</h1>
<div>We describe the steps to run this artifact.</div>
<h2>Hardware and OS setup</h2>
<div>1. This artifact has been run and tested on `x86_64` and `x64` architectures. However, we are unaware of any issues that would prevent this artifact from running on `x86` architectures.</div>
<p> </p>
<div>2. This artifact has been run and tested on Ubuntu `20.04.5 LTS` OS and Raspbian Linux version released on `2023-02-21`, both of which follow the Debian distro. However, we are unaware of any issues that would prevent this artifact from running on Fedora distros like CentOS and Red Hat Linux.</div>
<p> </p>
<h2>Rust installation and Cargo setup</h2>
<div>The repository uses the `Cargo` build tool. The compatibility between dependencies has been tested for Rust version `1.63`.</div>
<div> </div>
<div>3. Run the set of following commands to install the toolchain required to compile code written in Rust and create binary executable files.</div>
<div> </div>
<div><code> sudo apt-get update</code></div>
<div><code> sudo apt-get -y upgrade</code></div>
<div><code> sudo apt-get -y autoremove</code></div>
<div><code> sudo apt-get -y install build-essential</code></div>
<div><code> sudo apt-get -y install cmake</code></div>
<div><code> sudo apt-get -y install curl</code></div>
<div><code># Install rust (non-interactive)</code></div>
<div><code> curl --proto "=https" --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y</code></div>
<div><code> source HOME/.cargo/env</code></div>
<div><code> rustup install 1.63.0</code></div>
<div><code> rustup override set 1.63.0</code></div>
<div> </div>
<div>4. Build the repository using the following command. The command should be run in the directory containing the `Cargo.toml` file.</div>
<div> </div>
<div><code> cargo build --release</code></div>
<div><code> mkdir logs</code></div>
<div> </div>
<p> </p>
<div>5. Next, generate configuration files for nodes in the system using the following command. Make sure to create the directory (in this example, `testdata/hyb_4/`) before running this command.</div>
<div> </div>
<div><code> ./target/release/genconfig --base_port 8500 --client_base_port 7000 --client_run_port 9000 --NumNodes 4 --blocksize 100 --delay 100 --target testdata/hyb_4/ --local true</code></div>
<p> </p>
<div>6. After generating the configuration files, run the script `appxcon-test.sh` in the scripts folder with the following command line arguments. This command starts Delphi with four nodes.</div>
<div> </div>
<div><code> ./scripts/appxcon-test.sh {epsilon} {rho} {Delta} testdata/hyb_4/syncer</code></div>
<div> </div>
<div>7. Substitute desired values of \epsilon,\rho_0,\Delta\epsilon=1,\rho_0=10,\Delta=100000v_i to each node. This logic can be changed to make nodes start with custom input values.</div>
<div> </div>
<div>8. The outputs are logged into the `syncer.log` file in logs directory. The outputs of each node are printed in a JSON format, along with the amount of time the node took to terminate the protocol.</div>
<div> </div>
<div>9. Running the FIN ACS protocol requires additional configuration. FIN uses BLS threshold signatures to generate common coins necessary for proposal election and Binary Byzantine Agreement. This setup includes a master public key in the `pub` file, nnn=16,64,112,160 in the benchmark folder, in zip files `tkeys-{n}.tar.gz`. After generating these files, place them in the configuration directory (`testdata/hyb_4` in this example) and run the following command (We already performed this step and have these files ready in `testdata/hyb_4` folder).</div>
<div> </div>
<div><code># Kill previous processes running on these ports</code></div>
<div><code> sudo lsof -ti:7000-7015 | xargs kill -9</code></div>
<div><code> ./scripts/fin-test.sh testdata/hyb_4/syncer</code></div>
<div> </div>
<p> </p>
<div>10. Similarly, Abraham et al.'s Approximate Agreement protocol can be run using the following command.</div>
<div> </div>
<div><code># Kill previous processes running on these ports</code></div>
<div><code> sudo lsof -ti:7000-7015 | xargs kill -9</code></div>
<div><code> ./scripts/abraham-test.sh {epsilon} {delta} {Delta} testdata/hyb_4/syncer</code></div>
<div> </div>
<div>The parameters {epsilon} and {delta} must be equal in this context to yield Abraham et al.'s protocol. {Delta} must be set to be equal to the difference between honest inputs `M-m`. Example configuration run includes the following command.</div>
<div> </div>
<div><code> ./scripts/abraham-test.sh 2 2 20 testdata/hyb_4/syncer</code></div>
<div> </div>
<p> </p>
<div>
<h2>Running in AWS</h2>
<div>We utilize the code in the [Narwhal](https://github.com/MystenLabs/sui/tree/main/narwhal/benchmark) repository to execute code in AWS. This repository uses `fabric` to spawn AWS instances, install Rust, and build the repository on individual machines. Please refer to the `benchmark` directory for more instructions about reproducing the results in the paper.</div>
<br>
<h2>Running in Raspberry-Pi testbed</h2>
<div>We described detailed instructions to reproduce the results in the paper in the Raspberry-Pi device testbed in the `benchmark/raspberry-pi` directory.</div>
</div>
<p> </p>
<h1>System architecture</h1>
<div>Each node runs as an independent process, which communicates with other nodes through sockets. Apart from the nodes running the protocol, the system also spawns a process called `syncer`. The `syncer` is responsible for measuring latency of completion. It reliably measures the system's latency by issuing `START` and `STOP` commands to all nodes. The nodes begin executing the protocol only after the `syncer` verifies that all nodes are online, and issues the `START` command by sending a message to all nodes. Further, the nodes send a `TERMINATED` message to the `syncer` once they terminate the protocol. The `syncer` records both start and termination times of all processes, which allows it to accurately measure the latency of each protocol.</div>
<p> </p>
<h1>Dependencies</h1>
<div>The artifact uses multiple Rust libraries for various functionalities. We give a list of all dependencies used by the artifact in the `Cargo.lock` file. `Cargo` automatically manages these dependencies and fetches the specified versions from the `crates.io` repository manager.</div>
<p> </p>
<h1>Code Organization</h1>
<div>The artifact is organized into the following modules of code.</div>
<div>1. The `config` directory contains code pertaining to configuring each node in the distributed system. Each node requires information about port to use, network addresses of other nodes, symmetric keys to establish pairwise authenticated channels between nodes, and protocol specific configuration parameters like values of . Code related to managing and parsing these parameters is in the `config` directory. This library has been borrowed from the `libchatter` (https://github.com/libdist-rs/libchatter-rs) repository.</div>
<p> </p>
<div>2. The `crypto` directory contains code that manages the pairwise authenticated channels between nodes. Mainly, nodes use Message Authentication Codes (MACs) for message authentication. This repo manages the required secret keys and mechanisms for generating MACs. This library has been borrowed from the `libchatter` (https://github.com/libdist-rs/libchatter-rs) repository.</div>
<p> </p>
<div>3. The `crypto_blstrs` directory contains code that enables nodes to toss common coins from BLS threshold signatures. This library has been borrowed from the `apss` (https://github.com/ISTA-SPiDerS/apss) repository.</div>
<p> </p>
<div>4. The `types` directory governs the message serialization and deserialization. Each message sent between nodes is serialized into bytecode to be sent over the network. Upon receiving a message, each node deserializes the received bytecode into the required message type after receiving. This library has been written on top of the library from `libchatter` (https://github.com/libdist-rs/libchatter-rs) repository.</div>
<p> </p>
<div>5. *Networking*: This repository uses the `libnet-rs` (https://github.com/libdist-rs/libnet-rs) networking library. Similar libraries include networking library from the `narwhal` (https://github.com/MystenLabs/sui/tree/main/narwhal/) repository. The nodes use the `tcp` protocol to send messages to each other.</div>
<p> </p>
<div>6. The `tools` directory consists of code that generates configuration files for nodes. This library has been borrowed from the `libchatter` (https://github.com/libdist-rs/libchatter-rs) repository.</div>
<p> </p>
<div>7. The `consensus` directory contains the implementations of various protocols. Primarily, it contains implementations of Abraham et al.'s approximate agreement protocol in the `hyb_appxcon` subdirectory, `delphi` protocol in the `delphi` subdirectory, and FIN protocol in `fin` subdirectory. Each protocol contains a `context.rs` file, which contains a function named `spawn` from where the protocol's execution starts. This function is called by the `node` library in the `node` folder. This library contains a `main.rs` file, which spawns an instance of a node running the respective protocol by invoking the `spawn` function.</div>
<p> </p>
<h1>References</h1>
<blockquote>
<div>[1] Duan, Sisi, Xin Wang, and Haibin Zhang. "Fin: Practical signature-free asynchronous common subset in constant time." In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, pp. 815-829. 2023.</div>
<div> </div>
<div>[2] Abraham, Ittai, Yonatan Amit, and Danny Dolev. "Optimal resilience asynchronous approximate agreement." In Principles of Distributed Systems: 8th International Conference, OPODIS 2004, Grenoble, France, December 15-17, 2004, Revised Selected Papers 8, pp. 229-239. Springer Berlin Heidelberg, 2005.</div>
</blockquote>
Focused laser spike dewetting as a method to probe rheology of polymer thin films
No full textThin polymer films whose thickness ranges from fractions of a nanometer to several micrometers have been in high demand over the past few years in several industries. Their high surface area to volume ratio and the potential for low-cost processing with minimal material usage while fulfilling purpose requirements make them very useful. However, these films behave differently from bulk materials and majority of polymer fabrication processes involve polymer flow. Hence the study of polymer thin film rheology becomes crucial. Bulk measurement of rheology is well established, but it has disadvantages in that it requires a lot of material and may not capture thin film physics. Previous studies have demonstrated dewetting of thin polymer films to study film material stability and properties. This study seeks to use focused laser spike (FLaSk) dewetting as a method to probe rheology of thin material films. The method is used to extract materials properties of three thin films – Polystyrene (PS), Poly –4–hydroxystyrene (PHS) and N, N′-Bis (3 – methylphenyl)–N, N′-diphenylbenzidine (TPD) having different glass transition temperatures,M.S.Includes bibliographical referencesby Adithya Sridha
The contribution of the United Nations to the development of international space law
No full textThe international legal framework for outer space activities has largely been developed through the consensus process within the Vienna-based United Nations Committee on the Peaceful Uses of Outer Space (UNCOPUOS), the primary multilateral fora dealing with the exploration and use of outer space for peaceful purposes. The UNCOPUOS has made a remarkable contribution to the development of the international regulatory framework for space through the adoption of five binding Treaties, five sets of United Nations General Assembly (UNGA) Principles, as well as an array of other ‘soft law’ instruments. This chapter examines the development of this international regulatory framework within the UNCOPUOS, and the major role it continues to play in promoting international cooperation in the field of space exploration. Lastly, it discusses the evolution of this framework within the security perspective of space activities addressed by the First Committee of the UNGA and in the Conference on Disarmament (CD)
RDMA-based Plugin Design and Profiler for Apache and Enterprise Hadoop Distributed File system
No full textDelphi: Efficient Asynchronous Approximate Agreement for Distributed Oracles
No full text<h1>Delphi: Asynchronous Approximate Agreement for Distributed Oracles</h1>
<div>This repository contains a Rust implementation of the following distributed oracle agreement protocols.</div>
<div> </div>
<div>1. Delphi AAA protocol</div>
<div>2. FIN ACS protocol [1]</div>
<div>3. Abraham et al. AAA protocol [2]</div>
<div> </div>
<div>The repository uses the libchatter networking library available [here](https://github.com/libdist-rs/libchatter-rs). This code has been written as a research prototype and has not been vetted for security. Therefore, this repository can contain serious security vulnerabilities. Please use at your own risk.</div>
<div> </div>
<div>Please consider citing our paper if you use this artifact.</div>
<blockquote>
<div>Delphi: Efficient Asynchronous Approximate Agreement for Distributed Oracles</div>
<div>Akhil Bandarupalli, Adithya Bhat, Saurabh Bagchi, Aniket Kate, Chen-Da Liu-Zhang, and Michael K. Reiter</div>
<div>To appear at 54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2024.</div>
</blockquote>
<div> </div>
<h2>Dataset</h2>
<div>The repository also contains a dataset containing values of prominent cryptocurrencies polled from 12 cryptocurrency exchanges. Details are available in the `dataset` folder.</div>
<div> </div>
<h1>Quick Start</h1>
<div>We describe the steps to run this artifact.</div>
<h2>Hardware and OS setup</h2>
<div>1. This artifact has been run and tested on `x86_64` and `x64` architectures. However, we are unaware of any issues that would prevent this artifact from running on `x86` architectures.</div>
<p> </p>
<div>2. This artifact has been run and tested on Ubuntu `20.04.5 LTS` OS and Raspbian Linux version released on `2023-02-21`, both of which follow the Debian distro. However, we are unaware of any issues that would prevent this artifact from running on Fedora distros like CentOS and Red Hat Linux.</div>
<p> </p>
<h2>Rust installation and Cargo setup</h2>
<div>The repository uses the `Cargo` build tool. The compatibility between dependencies has been tested for Rust version `1.63`.</div>
<div> </div>
<div>3. Run the set of following commands to install the toolchain required to compile code written in Rust and create binary executable files.</div>
<div> </div>
<div><code> sudo apt-get update</code></div>
<div><code> sudo apt-get -y upgrade</code></div>
<div><code> sudo apt-get -y autoremove</code></div>
<div><code> sudo apt-get -y install build-essential</code></div>
<div><code> sudo apt-get -y install cmake</code></div>
<div><code> sudo apt-get -y install curl</code></div>
<div><code># Install rust (non-interactive)</code></div>
<div><code> curl --proto "=https" --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y</code></div>
<div><code> source HOME/.cargo/env</code></div>
<div><code> rustup install 1.63.0</code></div>
<div><code> rustup override set 1.63.0</code></div>
<div> </div>
<div>4. Build the repository using the following command. The command should be run in the directory containing the `Cargo.toml` file.</div>
<div> </div>
<div><code> cargo build --release</code></div>
<div><code> mkdir logs</code></div>
<div> </div>
<p> </p>
<div>5. Next, generate configuration files for nodes in the system using the following command. Make sure to create the directory (in this example, `testdata/hyb_4/`) before running this command.</div>
<div> </div>
<div><code> ./target/release/genconfig --base_port 8500 --client_base_port 7000 --client_run_port 9000 --NumNodes 4 --blocksize 100 --delay 100 --target testdata/hyb_4/ --local true</code></div>
<p> </p>
<div>6. After generating the configuration files, run the script `appxcon-test.sh` in the scripts folder with the following command line arguments. This command starts Delphi with four nodes.</div>
<div> </div>
<div><code> ./scripts/appxcon-test.sh {epsilon} {rho} {Delta} testdata/hyb_4/syncer</code></div>
<div> </div>
<div>7. Substitute desired values of \epsilon,\rho_0,\Delta\epsilon=1,\rho_0=10,\Delta=100000v_i to each node. This logic can be changed to make nodes start with custom input values.</div>
<div> </div>
<div>8. The outputs are logged into the `syncer.log` file in logs directory. The outputs of each node are printed in a JSON format, along with the amount of time the node took to terminate the protocol.</div>
<div> </div>
<div>9. Running the FIN ACS protocol requires additional configuration. FIN uses BLS threshold signatures to generate common coins necessary for proposal election and Binary Byzantine Agreement. This setup includes a master public key in the `pub` file, nnn=16,64,112,160 in the benchmark folder, in zip files `tkeys-{n}.tar.gz`. After generating these files, place them in the configuration directory (`testdata/hyb_4` in this example) and run the following command (We already performed this step and have these files ready in `testdata/hyb_4` folder).</div>
<div> </div>
<div><code># Kill previous processes running on these ports</code></div>
<div><code> sudo lsof -ti:7000-7015 | xargs kill -9</code></div>
<div><code> ./scripts/fin-test.sh testdata/hyb_4/syncer</code></div>
<div> </div>
<p> </p>
<div>10. Similarly, Abraham et al.'s Approximate Agreement protocol can be run using the following command.</div>
<div> </div>
<div><code># Kill previous processes running on these ports</code></div>
<div><code> sudo lsof -ti:7000-7015 | xargs kill -9</code></div>
<div><code> ./scripts/abraham-test.sh {epsilon} {delta} {Delta} testdata/hyb_4/syncer</code></div>
<div> </div>
<div>The parameters {epsilon} and {delta} must be equal in this context to yield Abraham et al.'s protocol. {Delta} must be set to be equal to the difference between honest inputs `M-m`. Example configuration run includes the following command.</div>
<div> </div>
<div><code> ./scripts/abraham-test.sh 2 2 20 testdata/hyb_4/syncer</code></div>
<div> </div>
<p> </p>
<div>
<h2>Running in AWS</h2>
<div>We utilize the code in the [Narwhal](https://github.com/MystenLabs/sui/tree/main/narwhal/benchmark) repository to execute code in AWS. This repository uses `fabric` to spawn AWS instances, install Rust, and build the repository on individual machines. Please refer to the `benchmark` directory for more instructions about reproducing the results in the paper.</div>
<br>
<h2>Running in Raspberry-Pi testbed</h2>
<div>We described detailed instructions to reproduce the results in the paper in the Raspberry-Pi device testbed in the `benchmark/raspberry-pi` directory.</div>
</div>
<p> </p>
<h1>System architecture</h1>
<div>Each node runs as an independent process, which communicates with other nodes through sockets. Apart from the nodes running the protocol, the system also spawns a process called `syncer`. The `syncer` is responsible for measuring latency of completion. It reliably measures the system's latency by issuing `START` and `STOP` commands to all nodes. The nodes begin executing the protocol only after the `syncer` verifies that all nodes are online, and issues the `START` command by sending a message to all nodes. Further, the nodes send a `TERMINATED` message to the `syncer` once they terminate the protocol. The `syncer` records both start and termination times of all processes, which allows it to accurately measure the latency of each protocol.</div>
<p> </p>
<h1>Dependencies</h1>
<div>The artifact uses multiple Rust libraries for various functionalities. We give a list of all dependencies used by the artifact in the `Cargo.lock` file. `Cargo` automatically manages these dependencies and fetches the specified versions from the `crates.io` repository manager.</div>
<p> </p>
<h1>Code Organization</h1>
<div>The artifact is organized into the following modules of code.</div>
<div>1. The `config` directory contains code pertaining to configuring each node in the distributed system. Each node requires information about port to use, network addresses of other nodes, symmetric keys to establish pairwise authenticated channels between nodes, and protocol specific configuration parameters like values of . Code related to managing and parsing these parameters is in the `config` directory. This library has been borrowed from the `libchatter` (https://github.com/libdist-rs/libchatter-rs) repository.</div>
<p> </p>
<div>2. The `crypto` directory contains code that manages the pairwise authenticated channels between nodes. Mainly, nodes use Message Authentication Codes (MACs) for message authentication. This repo manages the required secret keys and mechanisms for generating MACs. This library has been borrowed from the `libchatter` (https://github.com/libdist-rs/libchatter-rs) repository.</div>
<p> </p>
<div>3. The `crypto_blstrs` directory contains code that enables nodes to toss common coins from BLS threshold signatures. This library has been borrowed from the `apss` (https://github.com/ISTA-SPiDerS/apss) repository.</div>
<p> </p>
<div>4. The `types` directory governs the message serialization and deserialization. Each message sent between nodes is serialized into bytecode to be sent over the network. Upon receiving a message, each node deserializes the received bytecode into the required message type after receiving. This library has been written on top of the library from `libchatter` (https://github.com/libdist-rs/libchatter-rs) repository.</div>
<p> </p>
<div>5. *Networking*: This repository uses the `libnet-rs` (https://github.com/libdist-rs/libnet-rs) networking library. Similar libraries include networking library from the `narwhal` (https://github.com/MystenLabs/sui/tree/main/narwhal/) repository. The nodes use the `tcp` protocol to send messages to each other.</div>
<p> </p>
<div>6. The `tools` directory consists of code that generates configuration files for nodes. This library has been borrowed from the `libchatter` (https://github.com/libdist-rs/libchatter-rs) repository.</div>
<p> </p>
<div>7. The `consensus` directory contains the implementations of various protocols. Primarily, it contains implementations of Abraham et al.'s approximate agreement protocol in the `hyb_appxcon` subdirectory, `delphi` protocol in the `delphi` subdirectory, and FIN protocol in `fin` subdirectory. Each protocol contains a `context.rs` file, which contains a function named `spawn` from where the protocol's execution starts. This function is called by the `node` library in the `node` folder. This library contains a `main.rs` file, which spawns an instance of a node running the respective protocol by invoking the `spawn` function.</div>
<div>
<div> </div>
<h1>Running Remote Benchmarks on AWS</h1>
<div>Forked from (Narwhal) [https://github.com/asonnino/narwhal].</div>
<br>
<div>This document explains how to benchmark the codebase and read benchmarks' results. It also provides a step-by-step tutorial to run benchmarks on [Amazon Web Services (AWS)](https://aws.amazon.com) accross multiple data centers (WAN).</div>
<br>
<h2>Setup</h2>
<div>The core protocols are written in Rust, but all benchmarking scripts are written in Python and run with [Fabric](http://www.fabfile.org/). To run the remote benchmark, install the python dependencies:</div>
<br>
<div><code> cd benchmark/</code></div>
<div><code> pip install -r requirements.txt</code></div>
<br>
<div>You also need to install [tmux](https://linuxize.com/post/getting-started-with-tmux/#installing-tmux) (which runs all nodes and clients in the background).</div>
<br>
<h2>AWS Benchmarks</h2>
<div>This repo integrates various python scripts to deploy and benchmark the codebase on [Amazon Web Services (AWS)](https://aws.amazon.com). They are particularly useful to run benchmarks in the WAN, across multiple data centers. This section provides a step-by-step tutorial explaining how to use them.</div>
<br>
<h3>Step 1. Set up your AWS credentials</h3>
<div>Set up your AWS credentials to enable programmatic access to your account from your local machine. These credentials will authorize your machine to create, delete, and edit instances on your AWS account programmatically. First of all, [find your 'access key id' and 'secret access key'](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-creds). Then, create a file `~/.aws/credentials` with the following content:</div>
<div>```</div>
<div>[default]</div>
<div>aws_access_key_id = YOUR_ACCESS_KEY_ID</div>
<div>aws_secret_access_key = YOUR_SECRET_ACCESS_KEY</div>
<div>```</div>
<div>Do not specify any AWS region in that file as the python scripts will allow you to handle multiple regions programmatically.</div>
<br>
<h3>Step 2. Add your SSH public key to your AWS account</h3>
<div>You must now [add your SSH public key to your AWS account](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html). This operation is manual (AWS exposes little APIs to manipulate keys) and needs to be repeated for each AWS region that you plan to use. Upon importing your key, AWS requires you to choose a 'name' for your key; ensure you set the same name on all AWS regions. This SSH key will be used by the python scripts to execute commands and upload/download files to your AWS instances.</div>
<div>If you don't have an SSH key, you can create one using [ssh-keygen](https://www.ssh.com/ssh/keygen/):</div>
<div><code> ssh-keygen -f ~/.ssh/aws</code></div>
<div> </div>
<br>
<h3>Step 3. Configure the testbed</h3>
<div>The file [settings.json](https://github.com/asonnino/narwhal/blob/master/benchmark/settings.json) (located in [narwhal/benchmarks](https://github.com/asonnino/narwhal/blob/master/benchmark)) contains all the configuration parameters of the testbed to deploy. Its content looks as follows:</div>
<div>```json</div>
<div><code>{</code></div>
<div><code>"key": {</code></div>
<div><code>"name": "aws",</code></div>
<div><code>"path": "/absolute/key/path"</code></div>
<div><code>},</code></div>
<div><code>"port": 8500,</code></div>
<div><code>"client_base_port": 9000,</code></div>
<div><code>"client_run_port": 9500,</code></div>
<div><code>"repo": {</code></div>
<div><code>"name": "delphi-rs",</code></div>
<div><code>"url": "https://github.com/akhilsb/delphi-rs.git",</code></div>
<div><code>"branch": "master"</code></div>
<div><code>},</code></div>
<div><code>"instances": {</code></div>
<div><code>"type": "t2.micro",</code></div>
<div><code>"regions": ["us-east-1","us-east-2","us-west-1","us-west-2","ca-central-1", "eu-west-1", "ap-southeast-1", "ap-northeast-1"]</code></div>
<div><code>}</code></div>
<div><code>}</code></div>
<div>```</div>
<div>The first block (`key`) contains information regarding your SSH key:</div>
<div>```json</div>
<div><code>"key": {</code></div>
<div><code>"name": "aws",</code></div>
<div><code>"path": "/absolute/key/path"</code></div>
<div><code>},</code></div>
<div>```</div>
<div>Enter the name of your SSH key; this is the name you specified in the AWS web console in step 2. Also, enter the absolute path of your SSH private key (using a relative path won't work).</div>
<br><br>
<div>The second block (`ports`) specifies the TCP ports to use:</div>
<div>```json</div>
<div><code>"port": 8500,</code></div>
<div><code>"client_base_port": 9000,</code></div>
<div><code>"client_run_port": 9500,</code></div>
<div>```</div>
<div>The artifact requires a number of TCP ports for communication between the processes. Note that the script will open a large port range (5000-10000) to the WAN on all your AWS instances.</div>
<br>
<div>The third block (`repo`) contains the information regarding the repository's name, the URL of the repo, and the branch containing the code to deploy:</div>
<div>```json</div>
<div><code>"repo": {</code></div>
<div><code>"name": "delphi-rs",</code></div>
<div><code>"url": "https://github.com/akhilsb/delphi-rs.git",</code></div>
<div><code>"branch": "master"</code></div>
<div>},</div>
<div>```</div>
<div>Remember to update the `url` field to the name of your repo. Modifying the branch name is particularly useful when testing new functionalities without having to checkout the code locally.</div>
<br>
<div>The the last block (`instances`) specifies the [AWS instance type](https://aws.amazon.com/ec2/instance-types) and the [AWS regions](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-available-regions) to use:</div>
<div>```json</div>
<div><code>"instances": {</code></div>
<div><code>"type": "t2.micro",</code></div>
<div><code>"regions": ["us-east-1","us-east-2","us-west-1","us-west-2","ca-central-1", "eu-west-1", "ap-southeast-1", "ap-northeast-1"]</code></div>
<div><code>}</code></div>
<div>```</div>
<div>The instance type selects the hardware on which to deploy the testbed. For example, `t2.micro` instances come with 1 vCPU (1 physical core), and 1 GB of RAM. The python scripts will configure each instance with 300 GB of SSD hard drive. The `regions` field specifies the data centers to use. If you require more nodes than data centers, the python scripts will distribute the nodes as equally as possible amongst the data centers. All machines run a fresh install of Ubuntu Server 20.04.</div>
<br>
<h3>Step 4. Create a testbed</h3>
<div>The AWS instances are orchestrated with [Fabric](http://www.fabfile.org) from the file [fabfile.py](https://github.com/akhil-sb/delphi-rs/blob/master/benchmark/fabfile.py) (located in [delphi-rs/benchmarks](https://github.com/akhil-sb/delphi-rs/blob/master/benchmark)); you can list all possible commands as follows:</div>
<div>```</div>
<div><code> cd delphi-rs/benchmark</code></div>
<div><code>$ fab --list</code></div>
<div>```</div>
<div>The command `fab create` creates new AWS instances; open [fabfile.py](https://github.com/asonnino/narwhal/blob/master/benchmark/fabfile.py) and locate the `create` task:</div>
<div>```python</div>
<div><code>@task</code></div>
<div><code>def create(ctx, nodes=2):</code></div>
<div>...</div>
<div>```</div>
<div>The parameter `nodes` determines how many instances to create in *each* AWS region. That is, if you specified 8 AWS regi
Delphi: Efficient Asynchronous Approximate Agreement for Distributed Oracles
No full text<h1>Delphi: Asynchronous Approximate Agreement for Distributed Oracles</h1>
<div>This repository contains a Rust implementation of the following distributed oracle agreement protocols.</div>
<ol>
<li>Delphi Asynchronous Approximate Agreement (AAA) protocol</li>
<li>
<div>FIN Asynchronous Common Subset (ACS) protocol</div>
</li>
<li>Abraham et al. AAA protocol</li>
</ol>
<div>The repository uses the libchatter networking library available <a href="https://github.com/libdist-rs/libchatter-rs">here</a>. This code has been written as a research prototype and has not been vetted for security. Therefore, this repository can contain serious security vulnerabilities. Please use at your own risk.</div>
<p> </p>
<h1>Quick Start</h1>
<div>The repository uses the <code>Cargo</code> build tool. The compatibility between dependencies has been tested for Rust version <code>1.63</code>.</div>
<p> </p>
<div>Build the repository using the following command.</div>
<div> </div>
<div><code> cargo build --release</code></div>
<div> </div>
<div>Next, generate configuration files for nodes in the system using the following command.</div>
<div> </div>
<div><code> ./target/release/genconfig --base_port 8500 --client_base_port 7000 --client_run_port 9000 --NumNodes 4 --blocksize 100 --delay 100 --target testdata/hyb_4/ --local true</code></div>
<div> </div>
<div>After generating the configuration files, run the script <code>appxcon-test.sh</code> in the scripts folder with the following command line arguments. This command starts Delphi with four nodes.</div>
<div> </div>
<div><code> ./scripts/appxcon-test.sh {epsilon} {rho} {Delta} testdata/hyb_4/syncer</code></div>
<div> </div>
<div>Substitute desired values of \epsilon,\rho_0,\Delta\epsilon=1,\rho_0=10,\Delta=100000v_i to each node. This logic can be changed to make nodes start with custom input values.</div>
<div> </div>
<div>The outputs are logged into the <code>syncer.log</code> file in logs directory. The outputs of each node are printed in a JSON format, along with the amount of time the node took to terminate the protocol.</div>
<div> </div>
<div>Running the FIN ACS protocol requires additional configuration. FIN uses BLS threshold signatures to generate common coins necessary for proposal election and Binary Byzantine Agreement. This setup includes a master public key in the <code>pub</code> file, n partial secret keys (one for each node) as <code>sec0,...,sec3</code> files, and the n partial public keys as `pub0,...,pub3` files. We utilized the <code>crypto_blstrs</code> library in the <a href="https://github.com/ISTA-SPiDerS/apss">apss</a> repository to generate these keys.</div>
<p> </p>
<h2>Running in AWS</h2>
<div>We utilize the code in the <a href="https://github.com/MystenLabs/sui/tree/main/narwhal/benchmark">Narwhal</a> repository to execute code in AWS. This repository uses <code>fabric</code> to spawn AWS instances, install Rust, and build the repository on individual machines. Please refer to the <code>benchmark</code> directory for more instructions.</div>
<p> </p>
<h1>System architecture</h1>
<div>Each node runs as an independent process, which communicates with other nodes through sockets. Apart from the n$ nodes running the protocol, the system also spawns a process called <code>syncer</code>. The <code>syncer</code> is responsible for measuring latency of completion. It reliably measures the system's latency by issuing <code>START</code> and <code>STOP</code> commands to all nodes. The nodes begin executing the protocol only after the <code>syncer</code> verifies that all nodes are online, and issues the <code>START</code> command by sending a message to all nodes. Further, the nodes send a <code>TERMINATED</code> message to the <code>syncer</code> once they terminate the protocol. The <code>syncer</code> records both start and termination times of all processes, which allows it to accurately measure the latency of each protocol.</div>
<div> </div>
<h1>Reproducing results in the paper</h1>
<p>The paper submitted to DSN'24 contains four plots with details about the termination latencies of Delphi, FIN, and Abraham et al.'s AAA protocol on a set of inputs. These experiments were conducted in two testbeds: (a) A geo-distributed testbed on Amazon Web Services (AWS) EC2 instances with upto 160 instances spanning 8 AWS regions around the world, and (b) A distributed testbed of Raspberry Pi devices deployed in a laboratory environment at Purdue University. The evaluation results on AWS can be reproduced by following the instructions in the README.md file in the benchmark directory of the extracted tar.gz file attached to this artifact. These results include the termination latency and network bandwidth utilized by each of the three protocols. However, reproducing the evaluation on the Raspberry Pi testbed requires the testbed to be online. We only turn this testbed on when someone wants access to it and switch it off at all other times to conserve energy. Further, the user willing to access this testbed would require SSH access to these machines. Anyone willing to reproduce these results on this testbed can contact Akhil Bandarupalli at [email protected]. </p>
- …
