The success of cloud computing and the pay-as-you-go model has led to a lot of big data that requires the use of outsourced data storage, which provides accessibility from many devices and great reliability at a lower cost. However, outsourcing data to public clouds naturally raises security concerns. The workarounds to this include using encryption, a “trusted” public cloud service, or private cloud infrastructure. None of these, however, directly address the problem of hiding data accesses when using public cloud infrastructure. That is, until ORAM, which ensures servers don’t see data or operations. The contribution that this paper makes is that there is currently no way to run ACID transactions obliviously. The goal of this paper is to obliviously and efficiently implement serializable ACID transactions on top of untrusted cloud storage.

The challenges of this paper are centered around the goal of preserving workload independence while guaranteeing the ACID properties (Atomicity, Isolation, Consistency, and Durability) with good performance. In general, the lack of concurrency control is used to guarantee isolation and atomicity. Write back ordering for security rather than for durability helps with the C and D properties. Limit concurrency improves performance. The threat model offered by Obladi includes the clients and a trusted proxy in the TCB, but the cloud storage and communication with it are untrusted. To partition transactions into fixed sized epochs, Obladi uses delayed visibility, and each delay will commit notifications until the epoch ends. Within each epoch, the transactions are executed on the trusted proxy, and writes are buffered until the epoch ends. Delayed visibility also improves performance by reducing the number of requests processed by ORAM while also implementing multi-versioned concurrency control on top of single version ORAM. On the performance side, batches of requests are sent to ORAM, but construction is mostly sequential. Obladi makes the contribution of parallelizing ORAM while guaranteeing linearizability by ensuring operations with data dependencies are not executed in parallel.

The evaluation has both positives and negatives. On the bright side, Obladi’s overhead is not extremely slow. The three cases studies showed between 5x and 12x lower throughput. However, the batching design significantly increases latency, by up to 70x on TPC-C. However, applications with smaller write batches work better. The performance is also extremely sensitive to the epoch size. A small epoch size leads to transactions not finishing, while a large epoch size leads to idle time. As a result, the epoch size should be tuned to types of applications. The design of Obladi also relies on a centralized proxy, and applications may be identified. There’s also a question of if there are too many operations in a single transaction, potentially exceeding the batch size.

Some of the potential extensions could be based on the design of Obladi. First and foremost, while batching helps cut down on expensive security benefits, it’s clear that the latency is significant. There are many knobs that can be turned when configuring Obladi for a specific application. It could be interesting to investigate whether hyperparameter tuning of batch size, epoch size, and limit on the number of operations in a single transaction per application leads to better performance. A set of guidelines or third-party applications that can perform this tuning may improve evaluation, dodging suboptimal, avoidable configurations.